[Haskell-cafe] Human-friendly compiler errors for GHC

[Max Bolingbroke]

2008/7/13 Claus Reinke <claus.reinke at talk21.com>:
> 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