[the_af]

Not saying many Haskell compiler errors are obscure, especially for the uninitiated, but the particular error you picked as your first example is perfectly clear.

Haskell is telling you 'you tried to apply a string literal to an argument as if it were a function, but it's not! It's a string literal. By the way, the string I'm talking about is "foo", which you tried to apply to "bar" in the expression "foo bar"'.

Yikes? It seems pretty helpful to me :)

Your second example is better, though.

[thinkpad20]

Well like I said, once you see enough of these error messages you get a clear idea of how to parse them and understand what they're "really saying". But on first glance, and in particular for newcomers, the error message is rather arcane. And of course, in this instance it's quite straightforward because it's a very simple expression, with a rather clear problem. But consider when the error might be buried in a much more complicated expression, or the fact that it's not a function (or is a function, when you expected otherwise) might not be as clear. For example a curried function that has too many or not enough arguments applied.

Also, although from a compiler's point of view it might make sense, the wording "The function ‘"foo"’ is applied to one argument, but its type ‘[Char]’ has none" doesn't make sense. It's clearly not a function if it doesn't take an argument. The same error message would be far clearer if it said something similar to "The expression ‘"foo"’ is being used as a function, but it is of type ‘[Char]’".

Also these are just two examples I rattled off the top of my head; the fact is that while the compiler is incredibly helpful in making sure your code is correct, it's less helpful in explaining itself. But, I also realize that producing good error messages is hard, and (I assume) significantly less interesting to many on the GHC team.

[IanCal]

The output contains all you need, yes, but it would be nice if what you typed was added to the output. You wrote out a much more user friendly version.

Someone posted the output from Elm, which does this: https://news.ycombinator.com/item?id=11848467

Edit: checkout the elm error message page here http://elm-lang.org/blog/compilers-as-assistants

[the_af]

Agreed, Elm in these two examples is way nicer! It doesn't add information, but it presents it in a beginner-friendly way, which is commendable.

However, I'm left wondering... Elm seems to be using hardcoded knowledge about commonly used types such as strings and numbers in order to improve its error messages (I wonder why Haskell doesn't, by the way). What happens in Elm when an error occurs with more complex, user-defined types and operations?

[IanCal]

It looks like it's only the specific hint at the bottom that requires any custom knowledge about the types themselves.

If you're interested, there were a couple more examples shown elsewhere in this thread:

http://elm-lang.org/blog/compiler-errors-for-humans (an older version it seems)

https://twitter.com/st58/status/732908457217531904

https://twitter.com/GregorySchier/status/732830868562182144

Something I've just found is that the errors can also be output in a nice machine readable format, so the suggested fixes can be read in by your editor plugin.

And finally, this is wonderful, a specific repo for code that causes error messages and a request for people to submit error messages that are confusing: https://github.com/elm-lang/error-message-catalog

[masklinn]

In the "+" case, only the final hint is type-specific. The first error is kind-of type-specific but only distinguishes functions and non-functions.