Hacker News new | ask | show | jobs
by HelloNurse 3670 days ago
The first error message is good: it helpfully includes the exact expression that craps out, and it means, matching intuition about how Haskell should be compiled, that the expression "foo" "bar" could only make sense if "foo" were a function from [Char] (i.e. the type of "bar") to some type t, but unfortunately "foo" is a [Char]: everyone should understand it easily, even if gratuitously introducing other names (it and its type t) and details about the compiler making up type equations is highly inelegant.

The second error message, on the other hand, proves that the first one is a lucky accident.
2 comments
AlexCoventry 3670 days ago
Everything you say is true, but it took me about 90s of staring at the Haskell error before I parsed out exactly what it was objecting to, even though I knew exactly how the code was broken. Whereas it took me no discernible time to understand the Elm error messages. Some of it could be that parsing the Haskell message primed me for the Elm message, but it doesn't seem that way to me.
link
MustardTiger 3670 days ago
>The second error message, on the other hand, proves that the first one is a lucky accident.

No, the second error message just shows that there's more options there so the error message is vague and not very helpful. The first one is not an accident, it is the standard type mismatch error.

link
HelloNurse 3670 days ago
My point is that 1 2 should give the same type of error message as "foo" "bar", because it is the same kind of error (1 isn't a function with one or more arguments).

The compiler exposes that when numbers are involved it attempts (and fails) some fancy and unexpected reasoning involving forall, while with plain type constructors like [Char] it attempts (and fails) straightforward and intelligible pattern matching.

Figuring out the type of 1 and 2 might be more difficult than figuring out the type of "foo" and "bar", but the special rules should be hidden: a compiler that cares about practical usage would provide unified and clear error messages, possibly listing sets of alternative types it was unable to choose from.

link
MustardTiger 3669 days ago
>My point is that 1 2 should give the same type of error message as "foo" "bar", because it is the same kind of error

And my point is that no it should not. "1 2" is more ambiguous, it could be more things, hence there is a more ambiguous error message.

link