[Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)

[Claus Reinke]

One user's view of error message history, perhaps helpful to reformers:-)

Once upon a time, Hugs tended to have "better" error messages than GHC.

They still weren't perfect, mostly when begginners where confronted with
messages referring to advanced concepts - eg, Simon Thompson had a list 
of translations of the kind "if Hugs reports this, it most likely means that",
especially targetted to beginners in his courses, ie users who where unlikely 
to want things like 'Num (a->b)' instances, or find non-existing semicolons. 

(the advice to focus on the error location usually means that either the 
 error message is misleading or too difficult for the user to interpret - it
 is a standard fallback in all programming language implementations,
 but no more than that; if we rely on it too often, the messages aren't
 doing their job)

Even for more advanced users, it was helpful to get messages from
several implementations (at least Hugs and GHC) for tricky cases, just
to get different views from which to piece together a picture. This, sadly,
is not as well supported these days as it used to be, but getting multiple
"opinions" on type errors is still useful advice (if your code can be handled
by multiple implementations, or if a single implementation can offer multiple
views, eg, beginner/advanced or top-down/bottom-up or ..).

Then Simon PJ invested a lot of energy into improving GHC's error 
messages, so the balance changed. Error message complaints didn't
stop, though, and the error messages were improved further, with 
more text, and suggestions for possible fixes, etc.

The suggestions are sometimes misleading, and I've felt there has 
been too much weight on narrative text, to the exclusion of actual 
type information (it is a programming language, after all, so why 
don't the error messages give type signatures for context instead of 
trying to "talk" me through it in natural language, without further 
references to types!-), but discussions like the present show that 
Simon has been on the right track with that, for many users.

Still, I would really like a "just the facts, please" mode for GHC, 
with less text and more type signatures (especially for the contexts 
of type mismatches). Error messages simply not including the
information I need has become my main issue with GHC messages,
and seems to be a common thread over many tickets and threads
apparently discussing phrasing (eg, expected/inferred: who expects
and why, and what is the inference based on?).

Somewhere in between, much research has focussed on type errors,
and how to report them in general, and implementations like Helium 
have set out to target beginners with simpler error messages. (*)

As for fixes, concrete suggestions are most likely to be adopted,
but sometimes it just isn't clear how to improve the situation, and
sometimes, there is no single best solution (which has spawned
countless interesting papers on type-error reporting;-).

It you want to help, file tickets for messages you find unhelpful,
and make suggestions for possible improvements. Unfortunately,
there doesn't seem to be an "error message" component in GHC's
trac, so querying for relevant tickets is not straightforward. Simon
keeps a partial list of error message related tickets here (keeping
track of trac tickets - meta-trac?-):

http://hackage.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets

Just, please, keep in mind that there is no one-size-fits-all:
improving a message for one group of users might well make
it less useful for another group.

Claus

(*) A beginner mode for Haskell systems has often been suggested,
    even before Helium. Instead, error messages, and even language
    design decisions have been constrained by trying to serve everyone
    with a single mode. I'd have thought that Helium, and Dr Scheme,
    have sufficiently demonstrated the value of having separate levels
    of a language and the corresponding error messages.