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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
