Types don't match expressions in type error

[igloo]

Frederik Eaton points out in the thread starting  http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008748.html that with this program:

a x = x True ++ [1]

-- ok
b = a (const [2])

-- uninformative error message
c = a y

-- more informative
d = a ()

y = const ()

in the type error, for b the type doesn't match the expression: y has type a -> () but it claims to have infered () for it:

v.hs:8:6:
    Couldn't match expected type `[a]' against inferred type `()'
    In the first argument of `a', namely `y'
    In the expression: a y
    In the definition of `c': c = a y

(this example should be made into a testcase once we know what the error will look like).

[simonpj]

Frederick adds: Also, I don't know what other people will think, but something bothers me about the "In" on the third line - perhaps if we replaced, on just that line, "In" with "For":

>     Couldn't match expected type `Bool -> [a]'
>            against inferred type `()'
>     For the first argument of `a', namely `()'
>     In the expression: a ()
>     In the definition of `d': d = a ()

then it would help reinforce the idea that the given expression E := `()' is the referent of the words "expected" and "inferred" - i.e. that the first type is "expected" *of* E by the context, and the second type is "inferred" *for* E from other judgments. Does that make sense?

Otherwise, since from different perspectives both types are both expected and inferred, I think there is potential for confusion (the other perspective is, respecting the context).

[simonpj]

I have improved matters a bit. Now both the HEAD and 6.6 (I had to do them separately) say:

Foo7.hs:16:6:
    Couldn't match expected type `[a]' against inferred type `()'
      Expected type: Bool -> [a]
      Inferred type: Bool -> ()
    In the first argument of `a', namely `y'
    In the expression: a y

It's trickier to take up Frederick's second suggestion ("For" instead of "In") so I'm leaving that. But I hope this is an improvement. The error management code in TcUnify is rather tricky and ad hoc, I regret to say.

I'll leave this bug open for now, in case there are any other suggestions, but if not we'll close it.

Simon

[Frederik]

Thanks for fixing that so quickly, that will be useful.

I'm surprised that the s/In/For/ change is more difficult... I've had other people tell me that they aren't sure about the difference between what GHC means by "Expected" and "Inferred". I think changing the first preposition at some point to something unambiguous would be a good idea - "In" is not clear, and other prepositions, for instance "By", can create a meaning which is opposite to that which is intended.

[morabbin]

For/In issue not resolved in 7.6.1.

[igloo]

Simon, if For/In is tricky, then I think we should just close this.