Type checker's expected and inferred types (reformatted)

[Scott Turner]

On Wednesday 28 October 2009 08:14:46 John Lato wrote:
> >> Isaac Dupree <ml at isaac.cedarswampstudios.org> 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.