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

On Wednesday 28 October 2009 08:14:46 John Lato wrote:

...

...

Isaac Dupree wrote:

...

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)

This is how I understand this process

1. checker infers x :: [a] from 'length x' 2. checker infers (3 + x) :: [a] from (+) and step 1 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 4. conflict - checker expects (length x) :: [a] from step 3 and infers (length x) :: Int from definition of 'length'.

Even with this simple example the error message given doesn't directly point to the problem. I don't think it's uncommon for there to be more steps in practice. I frequently find myself adding explicit type signatures to let-bound functions to debug these. This is a pain because it also usually involves enabling ScopedTypeVariables.

I'll second that. On Saturday 24 October 2009 15:21:51 Albert Y. C. Lai wrote:

I find it unnecessary to "decrypt" the two words "expected" and "inferred". They have their own definitions and they stand for themselves;

On the contrary, this is a perfect example of why the error message's choice of words is bad. One type is "expected" and the other is "inferred". In the example the contextual type [a] is inferred via steps 1-2-3, and the internal type Int is determined so trivially that the "inferred" designation is somewhere between confusing and misleading. I'd love to see "expected" kept, and "inferred" removed from the message.