[m-dev.] new option for library modules

[Julien Fischer]

Hi Zoltan,

On Mon, 20 Dec 2021, Zoltan Somogyi wrote:

> We could help prevent issues such as the one that caused the
> most recent problem reported on m-users if we added an option,
> called maybe --this-is-mercury-stdlib-module, that behaved like this:
>
> - If it is off, the default, then it would generate a warning if the
>  name of the module compiled with is on the list of the names of
>  Mercury standard library modules.
>
> - If it is off, which it would be in our library directory, it would generate
>  a warning if the name of the module compiled with it is *not*
>  on that list.

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

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

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

Julien.