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