[m-rev.] for review: add "did you mean" reminders for mistyped predicate names

[Zoltan Somogyi]

On 2023-09-26 01:22 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>> Yep, though it is worth doing only for the entities that people generate
>> undefined references to reasonably often. Besides predicates and function
>> symbols, I think only type names, and maybe module names, may be
>> frequent enough. I am pretty sure that inst, mode and event names are not.
>> (Field names count as function names, due to field access syntax.)
>> Can you think of any others?
> 
> Typeclass names.

Right.

>>> I suggest imposing a limit on the number of close enough names that are
>>> printed, around a dozen should suffice; I can't imagine the resulting error
>>> messages being particularly meaningful if there are more.
>>
>> The code at the moment prints all the candidate strings that have
>> the same edit distance from the undefined reference. This means that
>> *if* there were ever more than 12 of them, we would have no useful
>> way to pick the 12 most likely to be the one the programmer wants.
>> I would punt this problem to the first time we ever encounter it for real.
>> I don't think that will ever happen on non-contrived code.
> 
> It seems like the kind of thing you could stumble into with machine
> generated Mercury code.  (Whether that counts as contrived or not ...)

Ok, will add a limit.

>> I agree, but the problem is not in the new code; it is given the sym_name
>> as qualified(unqualified(io"), "io__write_string"), i.e. it is given a string with
>> a double underscore in the *base* name. Given that __s as module separators
>> have gone the way of the dodo in  current code, I don't really feel like
>> chasing down the reason for that.
> 
> I don't think mixing module qualifiers has ever worked. We should
> consider dropping support for __ as a module qualifier.

And here I am just now bootchecking a possible fix that would allow
such mixing to take place, after my curiosity got too strong about why
the mixing didn't work.

That diff also deletes support for ":" as a module qualifier, which hasn't been
allowed by the manual for ages ...

>> There was a question about edit_distance.m that I forgot to ask in my
>> original email. Should we add a version of the find_closest_seq predicate
>> that explicitly works on strings? It would do all the required conversions
>> between strings and char lists, so users wouldn't have to. We could call it
>> find_closest_string.
> 
> I don't see a problem with adding.

Will do.

Zoltan.