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

[Claus Reinke]

> I agree this feature would be cool, I'm just not sure the possible
> memory/performance problems associated with loading all interfaces of
> all exposed modules in all packages (it would be most helpful but even
> more of a performance problem to even scan non-exposed packages) would
> be worth it. Probably it could be made practical by building a sort of
> index, which is cached on disk..

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.

Then again, we don't do fuzzy matching, only completion
of partial identifiers and suggesting possible qualified
names and imports for unqualified ones. 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;-).

A general comment: once there was a time when GHC error
messages were inferior to Hugs ones, then Simon PJ spent a
lot of time improving GHC's messages, until there came a time
when some of GHC's messages were too helpful - you couldn't
find the error in all the help provided. It used to be a good idea
to have several Haskell installations, just to be able to compare
error messages for tricky code.

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, ..

By all means, record unhelpful error messages as tickets,
especially, but not only, when you have an idea of the 
information that is missing/misleading in them.

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..).

Claus