[m-dev.] new option for library modules

[Zoltan Somogyi]

On Thu, 30 Dec 2021 16:16:19 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > I don't know. That was never *my* intention; I am happy both with
> > and without a stdlib package.
> 
> On the basis that the standard library is injecting over one hundred
> names into top-level module namespace and that certainly for some
> program domains, some of those names might clash, I think it would be
> desirable.

Agreed.

> That said, this is not a priority.

Which is exactly why I am not bothered by the status quo.

> > 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.
> 
> I can't speak for MSIL, but it's not a requirement for either the Java
> or C# backends.

I was basing this on a memory of the text under "1. Modules" in the
big comment at the top of mlds.m, which echoes your point above.
Saying "need" was too strong, I agree.

> > 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.
> 
> Module name components elided from the middle of a module name can
> always be resolved via module qualification.

Can it?

If you have both mod_a.mod_b.predname and mod_a.predname in scope,
how can you refer to the latter in a way that cannot refer to the former?

> My point is that it is
> currently possible to name modules (and the entities within in them) in
> such a way that is impossible to resolve the ambiguity in every
> direction.  I have attached an example to this mail. (IIRC there is
> another exmaple in Mantis somewhere).

I agree with this. However, if the above was not sufficient to convince you
of my point, I can tweak your example of your point into an example
of my point.

> While the example is contrived, this has occurred in practice; the
> parser / cadmium.parser instance I mentioned.  Of course the resolution
> in that case was to simply rename the cadmium version of the module.
> However, renaming may not be an option users always have, consider a
> program that is making use of two third-party libraries that have such
> a clash.

Agreed.

> > 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.
> 
> At this point in time, I don't think its worth addressing either.
> It is however, a hole in the language design -- I will see about
> adding something to the LIMITATIONS file.

That is a good idea. Thanks.

> (Speaking of which: are there any objections in me converting the
> LIMITATIONS file into Markdown and renaming -> LIMITATIONS.md?)

That conversion is a good idea.
 
> >> 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.
> 
> I have no objections to the "mercury_term_" suffix.

Will do.

> >>> 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.
> 
> I meant the latter; they are two possible names for the same option.

Then we are in sync. Thanks.

Zoltan.