From jfischer at opturion.com Mon Jan 13 16:26:33 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 13 Jan 2025 16:26:33 +1100 Subject: [m-dev.] "Did you mean ..." messages for module qualifiers Message-ID: Hi, 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? 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'?) Question: if we do find visible modules that are "close enough", should we even report the bit about the module not being imported? Julien. From zoltan.somogyi at runbox.com Mon Jan 13 16:59:08 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 Jan 2025 16:59:08 +1100 (AEDT) Subject: [m-dev.] "Did you mean ..." messages for module qualifiers In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 16:26:33 +1100, Julien Fischer 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. From jfischer at opturion.com Mon Jan 13 22:45:36 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 13 Jan 2025 22:45:36 +1100 Subject: [m-dev.] "Did you mean ..." messages for module qualifiers In-Reply-To: References: Message-ID: Hi Zoltan, On Mon, 13 Jan 2025 at 16:59, Zoltan Somogyi wrote: > > On Mon, 13 Jan 2025 16:26:33 +1100, Julien Fischer 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. From zoltan.somogyi at runbox.com Mon Jan 13 22:54:50 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 Jan 2025 22:54:50 +1100 (AEDT) Subject: [m-dev.] "Did you mean ..." messages for module qualifiers In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 22:45:36 +1100, Julien Fischer wrote: > Hi Zoltan, > > On Mon, 13 Jan 2025 at 16:59, Zoltan Somogyi wrote: > > > > On Mon, 13 Jan 2025 16:26:33 +1100, Julien Fischer 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. Agreed, but your email did not say anything about the ranges module being imported, so I assumed it wasn't. > > 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. We do not do so for other kinds of dym messages. The heuristic for "how big a difference is too big" is something we took from (I think) gcc, and it is dependent on name length, I think about one third replacement being the limit. Zoltan. From jfischer at opturion.com Mon Jan 13 23:06:34 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 13 Jan 2025 23:06:34 +1100 Subject: [m-dev.] "Did you mean ..." messages for module qualifiers In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 at 22:54, Zoltan Somogyi wrote: > > > > 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. > > Agreed, but your email did not say anything about the ranges module being > imported, so I assumed it wasn't. To be clear; the ranges module was imported in my original example. > > > 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. > > We do not do so for other kinds of dym messages. The heuristic for "how big > a difference is too big" is something we took from (I think) gcc, and it is > dependent on name length, I think about one third replacement being the limit. Whether that same heuristic is applicable to all the kinds of entity, you may want to generate dym messages for is an open question. I suggest we just start by using the existing heuristic and adjust if necessary. Julien. From zoltan.somogyi at runbox.com Mon Jan 13 23:10:59 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 Jan 2025 23:10:59 +1100 (AEDT) Subject: [m-dev.] "Did you mean ..." messages for module qualifiers In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 23:06:34 +1100, Julien Fischer wrote: > To be clear; the ranges module was imported in my original example. But for some strange reason, the import was not mentioned on the NSF webcast of the New Glenn launch, which was what I was mainly concentrating on at the time :-( > > > > 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. > > > > We do not do so for other kinds of dym messages. The heuristic for "how big > > a difference is too big" is something we took from (I think) gcc, and it is > > dependent on name length, I think about one third replacement being the limit. > > Whether that same heuristic is applicable to all the kinds of entity, > you may want > to generate dym messages for is an open question. I suggest we just start by > using the existing heuristic and adjust if necessary. Agreed. Zoltan.