[m-dev.] new option for library modules

[Julien Fischer]

Hi Zoltan,

On Sun, 26 Dec 2021, Zoltan Somogyi wrote:

> On Tue, 21 Dec 2021 11:24:26 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>> Would the check only catch exact matches, or would it also check for
>> submodules whose unqualfied or partially qualified name matches a
>> library module?  I have had problems with in several projects containing
>> modules named like:
>>
>>      cadmium
>>      cadmium.parser
>
> I was originally thinking about only exact matches, but you are right,
> we need to handle other kinds of "name confusion" as well.
>
>> (Arguably, that should be alright but you can end up with unresolvable
>> ambiguities as Mercury doesn't have a way to explicitly specify the top
>> of the module hierarchy.)
>
> Agreed. I therefore propose that we should generate a warning
> if the partial_sym_name_is_part_of_full test in mdbcomp/sym_name.m
> succeeds when passed the name of a Mercury stdlib module as the
> PartialSymName and the module name we are deciding whether
> to warn about as the CompleteSymName. If this test succeeds,
> then any reference to the stdlib module's name is ambiguous,
> even if fully qualified, since it could also be a reference to the user's module.

Agreed.

> I also propose to use simpler wording in the error message
> when the two module names are identical, and more extensive wording
> (explaining the above) when they are not identical but the above test still succeeds.

Agreed.

Some other questions / thoughts:

1. Is the intention still to push the standard library modules into a
"std" package (as mentioned in the comment in mdbcomp/builtin_modules.m)?

2. Does the language require a mechanism to explicitly denote the root
of the module hierarchy?

      <>.foo.bar
      <>.bar  ===> would only match a top-level module named 'bar', not
                   'foo.bar'

Here I am using '<>' to indicate the root of the module hierarchy; that
choice is for illustration only.

3. Do the stdlib modules 'parser' and 'lexer' need to be renamed?
Maybe to

     parser -> term_parser
     lexer -> term_lexer

Those names are a common source of conflict with user code.

>>> The second part would ensure that the list is not missing any entries.
>>>
>>> The list could have two halves, the publicly documented modules
>>> vs the rest, so that the warning in the first case could be a bit more
>>> expansive in the second case.
>>>
>>> One minor issue is that this would make adding a new module
>>> to the library a two-step process: either add the name to the list,
>>> then add the module,
>>
>> The first suggestion would making working on changes that add new
>> standard library modules really annoying.  Particularly, since some
>> standard library module names are not finalised until *after* they
>> are reviewed.
>>
>>> or add the module while disabling this option for it, then later undo
>>> the disabling.
>>
>> By adding an appropriate entry to the Mercury.options file?
>
> That was my initial intention, yes. But I agree with Peter, this
> extra step, though not onerous, is still annoying. I have come up
> with another way to reach the objective it was designed to reach.
>
> The option I proposed earlier, which Peter proposed be called
> --warn-redefine-stdlib-module, would now operate only when enabled,
> causing the above check to be made. library/LIB_FLAGS would
> contain --no-warn-redefine-stdlib-module, turning this check,
> and therefore the warning, off.
>
> Since the compiler wouldn't do anything with --no-warn-...,
> it wouldn't help us catch situations in which we add a module
> to the standard library without adding its name to the list
> of standard library module names. To fix this, I propose adding
> *yet another* new option, called maybe --output-stdlib-modules,
> that would have one task, which would be to set the op_mode
> to a new op_mode_query, called maybe opmq_output_stdlib_modules.
> We could then modify tools/bootcheck to compare the list of module
> names in the library directory against the output of the compiler
> with this option, reporting an error in the case of a mismatch.
>
> Opinions about these changes?

I don't have any objections to either of them.  I'm not convinced
that the latter has really been a particuarly great problem in the
past, but it can't hurt.

> And given that this updated proposal can generate warnings
> for nonexact module name matches, is the "redefine" part of
> --warn-redefine-stdlib-module still descriptive? Should the name
> be more like --warn-confusable-with-stdlib-module-name,
> or just --warn-confusable-with-stdlib?

I suggest:

     --warn-stdlib-module-shadowing with the synonym
     --warn-stdlib-shadowing

Julien.