Re: Type checker's expected and inferred types (reformatted)

David Menendez wrote:

On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree wrote:

...

David Menendez wrote:

...

The expected type is what the context wants (it's *ex*ternal). The inferred type is what the expression itself has (it's *in*ternal).

So inferring the type Maybe () for bar seems wrong. well, maybe GHC just gets it wrong enough of the time, that I got confused.

Or maybe ... When there are bound variables interacting, on the inside and outside, it gets confusing.

ghci: Prelude> \x -> (3+x) + (length x)

<interactive>:1:15: Couldn't match expected type `[a]' against inferred type `Int' In the second argument of `(+)', namely `(length x)' In the expression: (3 + x) + (length x) In the expression: \ x -> (3 + x) + (length x)

Your explanation of "expected" and "inferred" could make sense to me if the error message followed the "Couldn't match" line with, instead, "In the first argument of `length', namely `x'" because 'length' gives the context of expected list-type, but we've found out from elsewhere (a vague word) that 'x' needs to have type Int.

This had me confused for a while, but I think I've worked out what's happening. (+) is polymorphic, ...

Oh darn, it sounds like you're right. And polymorphism is so common. I just came up with that example randomly as the first nontrivial type-error-with-a-lambda I could think of... I wonder if it would help for the message to also output what it thinks the complete type of the function is (so far). I wonder if it could look something like this: Couldn't match expected type `[a]' against inferred type `Int' In the second argument of `(+) :: [a] -> [a]', namely `(length x) :: Int' (always, at the risk/tradeoff of taking up space with lots of useless information. sadly. hmm.) Ideally I would like GHC to pick a location for the error that's more intuitive, but that sounds like an awfully vague desire :-) -Isaac