[m-dev.] new option for library modules

[Julien Fischer]

Having hit send, I realised I had forgotten to attach the example
I mentioned ... here it is.

Julien.

On Thu, 30 Dec 2021, Julien Fischer wrote:

>
> 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.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ambig_modules.tar.gz
Type: application/gzip
Size: 468 bytes
Desc: 
URL: <http://lists.mercurylang.org/archives/developers/attachments/20211230/71ee521b/attachment.gz>