Type checker's expected and inferred types (reformatted)
1haskell at pkturner.org
Sat Oct 31 15:54:52 EDT 2009
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
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.
More information about the Glasgow-haskell-users