[Haskell-cafe] Re: Strange type error with associated type synonyms

[John Lato]

Hello,

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

> From: Bulat Ziganshin <bulat.ziganshin at gmail.com>
>
> 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