[m-dev.] "Did you mean ..." messages for module qualifiers

[Julien Fischer]

Hi Zoltan,

On Mon, 13 Jan 2025 at 16:59, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> On Mon, 13 Jan 2025 16:26:33 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > Currently, if a module qualified name has a module qualifier that does not
> > match one of the imported modules, or the module being compiled, we generate
> > an error message like the following:
> >
> >     foo.m:013: In clause for predicate `main'/2:
> >     foo.m:013:   error: call to undefined predicate `range.bar'/2.
> >     foo.m:013:   (The module `range' has not been imported.)
> >
> > The module `range' not being imported is one possible cause for this error.
> > Another possible cause for this error, as here, is that the user has
> > incorrectly typed the name of a module (in this case `ranges'). In my opinion,
> > some form of the "Did you mean ..." messages we generate in other circumstances
> > would be also be useful here, if we find a unrecognised module qualifier we
> > compute its distance from the names of the visible modules and report any that
> > are close enough.
> >
> > Question: should we generate "Did you mean ..." messages for module qualifiers?
>
> Yes, if we can. Generating dym messages requires knowing either *the* set of
> possible spellings you may mean, or a reasonable subset of that set. In this case,
> I am pretty sure that the compiler does NOT (currently) have access to the full
> set of module names in the program. It does have access to the subset of that set
> consisting of the set of imported and included module names, but that would not help
> in this case.

I disagree, if the unknown qualifier is within a sufficiently close
edit distance of some of
the imported or included modules, then it is very probable that the
user meant the
qualifier to be of one of those and just entered it incorrectly.

> We could extend the subset
>  by baking the set of standard library modules into the database used by the code
>   that generates dym messages, which would help in this case, and/or

That's a good idea.

> - by including the module names mentioned in any of the .int* and .*opt files
>   read in.
>
> Whether that would be big enough for dym messages to be useful depends on
> the kinds of misspellings people tend to write, and that is quite individual-dependent.

I think we would probably limit it to candidates that are within one
or two edits of the
unknown name.

> I don't tend to make such errors, so I cannot usefully guess how effective
> dym messages using those database would be.
>
> We *could* extend mmc --generate-dependencies to put the full list of modules
> into a file with a standard name, just to provide an authoritative database for
> this purpose. However, I would consider that overkill.

As would I.

Julien.