[m-dev.] new option for library modules

[Zoltan Somogyi]

On Wed, 29 Dec 2021 14:51:19 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > 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.

Will do.
 
> 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)?

I don't know. That was never *my* intention; I am happy both with
and without a stdlib package.

I believe the original cause of this idea was the need to use stdlib package
names in one of the MLDS *target* languages, either Java or C#, or
possibly even MSIL.

> 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.

I don't think that would fully solve the problem; you would also need
some way of indicating that there are no module name components
elided from the *middle* of a module name. In other words, just putting
<>. in front of a module name would *not* make that module name
fully module qualified.

While overall I feel that some such mechanism would be useful,
I also think its overall usefulness is quite small, so I would prefer
to work on something else.

> 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.

Agreed, though I would use "mercury_term_" as the prefix.
If you agree with that prefix, I will go ahead and do it.

> > 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

I am not sure what exactly you are proposing. Are those
a proposal for two separate options, or two possible names
for one option? I am confused about what "with the synonym"
means.

My proposal had one option, which would generate different
error message texts for exact and nonexact matches. I don't think
two separate options would help, because users who pick confusable
module names won't be aware of the need to pick *any* option.

I think I will implement my proposal with the internal option name
warn_stdlib_shadowing while we discuss what its user-visible name
should be :-)

Zoltan.