Very cool! Do you think there's any way you could separate it from  
the compiler, like Learner et al.'s SEMINAL work, which separates  
type error messages from the compiler?. Separation could help ensure  
this (and any other, similar) ideas don't accidentally introduce bugs  
into the compiler, and make it much easier for you to maintain. A  
very simple hack might be tod wrap ocamlc in a script that parses  
such error messages and then tokenizes the source file, looking for  
similar strings?

Cheers,
Yitzhak

On Oct 29, 2007, at 5:11 PM, Edgar Friendly wrote:

> One random little feature of GNAT that comes in handy for me is its
> habit of, when I misspell an identifier, giving me a possible  
> correction
> in its compile error message.  Spending some time with the 3.10.0
> sources, I have created a "second draft" patch creating this
> functionality in my favored language.
>
> Example:
> ========
>
> # /home/thelema/Projects/ocaml-custom/bin/ocamlc -o coml -I +lablgtk2
> lablgtk.cma gtkInit.cmo coml.ml
> File "coml.ml", line 61, characters 16-25:
> Unbound value is_arcive, possible misspelling of is_archive
>
> Impacts:
> ========
>
> Efficiency in the case of finding a mistake should be quite good,
> although this shouldn't matter too much since the compiler quits  
> pretty
> early in compilation when it finds an unbound identifier.
>
> In the case of no unbound identifiers, the cost is an extra try/with
> block around the standard lookup.  I haven't made any benchmarks,  
> though.
>
> I expect this code to have little long term maintenance issues - the
> major source of code changes was adding a "* string list" to a  
> number of
> exceptions to carry the list of possible correct spellings to the  
> point
> they get output by the compiler.  These exceptions are still usable as
> before with an empty list in this spot.
>
> It's possible the code has created opportunities for uncaught  
> exceptions
> in the compiler as I only checked for instances of "Not_found" in a  
> few
> files -- those which dealt with the Unbound_* exceptions.  Someone who
> knows the internals better might find places the "Found_nearly"
> exception that carries possible corrections might escape into.
>
>
> Dedicated to:
> Yaron Minsky and the team at Jane Street
>
> E.

-----------------------------
Yitzhak Mandelbaum