[m-dev.] new option for library modules

[Julien Fischer]

Hi Zoltan,

On Wed, 29 Dec 2021, Zoltan Somogyi wrote:

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

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

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.  That said, this is not a priority.

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

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

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

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.

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

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

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

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

Julien.