Comment author: @gasche

I think this is easy to do in a not-really-satisfying way, and too hard (or too invasive) to do right.

(1) The easy thing is to know about the modules of the standard library, and look in them for an identifier that is exactly the same as the one used (or possibly at a short edit distance but we probably don't want that), without using any kind of typing information. In your case, it would suggest both Array.map and List.map, and would also suggest Queue.map if that existed -- and not know anything about Core, even if that's what you're using.

(2) The very-hard thing to do would be to look into the set of functions that have the correct type in the current "programming environment" (the set of modules you use in your program). The current implementation will not scale to using type information (it's really harder and more invasive), and the notion of "programming environment" is not really well-defined for OCaml programs (you probably do not want all the .cmi in your include path to be traversed for typo suggestions, and today's compiler invocation don't have enough information to do something more refined).

I don't think it's realistic to expect (2) in a medium-term future in the compiler. I'm interested in your opinion but I think (1) would probably not improve the user experience.

It may be the case that some heuristics could substantially improve solution (1). For example we could consider only modules that are mentioned in the current compilation unit -- and their submodules. So if you used M.foo correctly the first time, and then use 'foo', it would correctly suggest M.foo.

Comment author: @johnwhitington

Thanks for the careful analysis. I think you're right. Method (2) is not a job for the top level, but for something like Merlin.

Actually, I wonder why autocorrect was included in the first place, since the toplevel has resisted various other attempts to make it less ascetic (relying on rlwrap for example, being a common whinge, not that I mind it).

So I suppose we either check all the standard library instead of just Pervasives, or leave it as is.

On another note, is there a way of doing edit distance which knows about the keyboard layout likely to be in use in the locale? My original confusion was, I suppose, that "map" and "max" are really not close together at all!

Comment author: @gasche

I'm not sure whether you know this already, but the typo-correction does not only take Pervasives into account, but everything that is present (unqualified) in the current typing environment: it will understand open-ed modules. In fact it can also follow module paths, eg. List.max will get corrected into List.map.
When I said that it cannot rely on type information, I meant that it used the faulty name (and the typing environment) as its only source of information, not the type of surrounding elements in the program context (eg. it couldn't reason that it's applied to a list, so it's List.map rather than Array.map).

I suspect trying to account for keyboard layout would hit diminishing return. Something that may be interesting is to allow displacement of several letters together (to account for the distance between "mod_float" and "float_mod" being relatively small in the mind of something that doesn't remember the exact name). But I would consider waiting a bit for more user experiences before starting to tweak ad infinitum.

(If you're reading this and have strong opinions on mistake-correcting techniques that could improve the user experience, I'm interested in feedback.)

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.