2008/7/13 Claus Reinke
That is the approach the haskellmode plugins for Vim take: build an index of Haddocumented identifiers once per installation, build an index of import-available identifiers once per :make.
The latter turns out to be a performance issue for large libraries, such as Gtk2hs, so some users had to switch it off, updating less frequently, the former doesn't seem to cause any problems.
Interesting. GHC would probably want to do something a bit smarter than an index at /installation/ time as the package environment is dynamic: 1. Create the index upon the first error message that needs it 2. On all subsequent error messages, update the index by rescanning packages whose versions have changed or have been newly installed 3. Cache this index on disk in some quick-to-read binary format This wouldn't actually be too hard, but is probably more effort than I'm willing to put in for an experimental weekend project!
Then again, we don't do fuzzy matching, only completion of partial identifiers and suggesting possible qualified names and imports for unqualified ones.
Agreed: doing fuzzy matching on >every< available identifier from all packages would truly suck. I would propose just looking for exact matches in non-imported modules for identifiers that are not in scope.
Completion alone can result in many matches, I'd expect fuzzy matching to be worse, and while edit distance is a useful criterion for well-chosen examples, I'd have to agree with those who have their doubts about its use in this context (but then, those who don't need a feature shouldn't stand in the way of those who do;-).
Well, noone has actually said they think fuzzy matching would be useful yet, so I suspect this patch is dead on the vine :). I've filed a ticket with the code anyway (http://hackage.haskell.org/trac/ghc/ticket/2442) so at least it's available for others to look at.
Things have levelled off since then, but there are still cases were longish fuzzy messages are provided by GHC when brief harsh messages would be more to the point - which wouldn't be a problem if the longer friendlier messages at least provided all the details of the short unfriendly ones, which isn't always the case. See, eg, #1928, #2360, #956, #589, #451, ..
...
It is an ongoing process, and balance is as important as perceived friendlyness, and lots of "friendly" suggestions without concrete, specific and useful help may result in a very unfriendly effect (think telephone/email support..).
These are interesting comments and tickets: thanks! I don't know where this kind of unbound-name suggestion we've talked about here fits in the spectrum of useful<->overwhelming, but I would like to think it's more towards the left end. It's easy to see why opinions would differ though. Cheers, Max