Hello, Apologies for the late contribution; I've been away recently. I have a very strong opinion on this, though.

From: Bulat Ziganshin

Thursday, May 28, 2009, 2:06:36 AM, HT wrote:

Prelude>> let a = 'a'; b = "b" in a==b

...

<interactive>:1:27:      Couldn't match expected type `Char' against inferred type `[Char]'      ....

...

Is the type of 'a' wrong or that of 'b'?

it is not important, well, at least we can live with it. Compiler should say:

First argument of == should be of type String while a is of type Char

I find this to be a somewhat important issue. If there weren't so many polymorphic functions it wouldn't be as big of a problem. The only reason the first argument of == should be a String is because the second argument is (or alternatively 2nd should be Char, etc.). For polymorphic functions, in which the type of one argument is fixed by another, I think the error message should ideally point out how the compiler is getting expected/inferred types. E.g. Couldn't match expected type `Char' against inferred type `[Char]' Type of [first argument] to `==' must match type of [second argument] where [first|second argument] is filled in with the appropriate expressions. I've become somewhat adept at figuring this out, but I think it would be helpful for those who haven't experienced it before. A related issue is with multiple function definitions. Here's a short example: foo n = ... where bar (Just a) = return $ somefunc a bar (Nothing) = somefunc n a = otherfunc assume that 'a' and 'n' have the same type. Now the type checker won't allow bar, because the two definitions have differing types. GHC's error message would ideally state that the definitions for 'bar' have differing types, but instead we get a message about mismatched types within one of the definitions. I know this example is rather contrived, but I don't have any real code to hand because I've fixed it already. You get a better message if you give a type signature for 'bar', but that requires lexical scoping (at least in my case), which means the code would no longer be Haskell98 (which it otherwise is IIRC). Cheers, John Lato