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

[Zoltan Somogyi]

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.

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

- 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 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 authorative database for
this purpose. However, I would consider that overkill.

> If so:
> 
> The way we currently generate DYM messages will result in there being multiple
> parenthetical parts in the error message:
> 
>     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.)
>     foo.m:013:   (Did you mean `ranges'?)
> 
> I think we need to generate DYM messages differently in this case, here's
> one suggestion:
> 
>     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 -- did you mean
>     foo.m:013:    the module `ranges'?)

I would be fine with either message, though I would also prefer the second.

> 
> Question: if we do find visible modules that are "close enough", should we even
> report the bit about the module not being imported?

I would accept either answer, but lean towards "yes". The reason is that
the first half of that last sentence gives the context for the second half.

Now back to the New Glenn launch.

Zoltan.