Compiler error using IO

[Bjorn Lisper]

Zhanyong Wan:
>> Here here. I think that the poor compiler error messages in Haskell are a
>> very major hurdle to learning the language.

Adrian Hey:
>Which compiler are you talking about? Bad error messages are not a valid
>critisism of the Haskell Language IMHO.

But there are language features in Haskell that makes it hard to produce
good error messages. Implicit typing, for instance: in an explicitly typed
language it is clear where in the code a type error occurs, but with
implicit typing there are often many possibilities and it is not always
evident where the culprit is. (Haskell compilers seem simply to report the
line where the unification fails. Am I right?)

Furthermore, semantically distant expressions can be syntactically close in
Haskell, so a syntax error actually gives a syntactically correct
expression.  Often this yields a type error instead, which then may show up
as an error message for some totally different part of the code...
Higher-orderness increases the risk.  An example is inadvertently writing
"f g y" for "f (g y)" which then is interpreted as "(f g) y" and will yield
incorrect constraints on the types of f, g, and y.

Is there any work being done on "intelligent" error messages for
higher-order implicitly typed languages? One could perhaps come up with
search strategies that tries to find a minimal number of program
transformations ("edit distance") that yields a syntactically correct and
well-typed program. For instance, in the case of type errors one could try
to search for the minimal number of definitions that have to be removed to
make the remaining program well-typed, and then report the removed
definitions as likely sources of the errors. Has anyone done this?

Björn Lisper