How to interpret compiler messages 'Couldn't match type: [b0] with: [a2] -> t :'?

I am learning the basic of Haskell and have trouble understanding compiler messages, that is how do types from the error messages correspond to the types from the expression.

If I intentionally give the compiler the wrong expression

sum map (+1) [1,2,3]   -- this is wrong on purpose to trigger a
                       -- compiler error

instead of the correct

sum (map (+1) [1,2,3])

then I would like to understand what the compiler output means.

For example:

:t sum map (+1) [1,2,3]

<interactive>:1:5: error:
    • Couldn't match type: [b0]
                     with: [a2] -> t
      Expected: (a0 -> b0) -> (a1 -> a1) -> [a2] -> t
        Actual: (a0 -> b0) -> [a0] -> [b0]
    • In the first argument of ‘sum’, namely ‘map’
      In the expression: sum map (+ 1) [1, 2, 3]

You want to apply sum to the result of all the rest, so you need either parenthesis,

sum (map (+1) [1,2,3])

or a $ which evaluates its rhs first before passing it to the lhs:

sum $ map (+1) [1,2,3]

The way you've written it, you're applying sum to map, just as you had written (sum map) (+1) [1,2,3], which doesn't make sense.

The error is simply telling you what there's an error

    • In the first argument of ‘sum’, namely ‘map’

which (map) has the Actual type (a0 -> b0) -> [a0] -> [b0] whereas the only way the compiler could make sense of the whole expression is if you had passed, instead of map, an entity of the Expected type (a0 -> b0) -> (a1 -> a1) -> [a2] -> t.

That expected type is simply a consequence of the further aruments you've passed to sum map. Indeed, sum map by itself is "fine", in the sense that it could in principle make sense. It's type is

:: (Foldable ((->) (a -> b)), Num ([a] -> [b])) => [a] -> [b]

where you can already see the absurdity of expecting a [a] -> [b] which is an instance of Num.

But that's ok, because the types are still polymorphic, not constrained enough for the compiler to work out that thing can't work.

At the moment you pass some types which have almost an exact type such as [1,2,3], which is a Num a => [a], and (+1), which is Num a => a -> a, then the compiler can't make head or tail of it, and tells you that.

Your question, in some way, could be rephrased as

> Why the type of x in \x -> sum x (+1) [1,2,3] is (Foldable t1, Num a1, Num a2, Num ((a1 -> a1) -> [a2] -> t2)) => t1 ((a1 -> a1) -> [a2] -> t2)?

And the answer is again is that that is as much as the compiler can do to try making types check.

Also, look at this example,

sum (:) (+1) [1,2,3]

where I'm passing (:) instead of map. The error is slightly different:

<interactive>:37:5: error:
    • Couldn't match type: [a0]
                     with: [a2] -> t
      Expected: a0 -> (a1 -> a1) -> [a2] -> t
        Actual: a0 -> [a0] -> [a0]
    • In the first argument of ‘sum’, namely ‘(:)’
      In the expression: sum (:) (+ 1) [1, 2, 3]

See how it compares to yours:

<interactive>:1:5: error:
    • Couldn't match type: [b0]
                     with: [a2] -> t
      Expected: (a0 -> b0) -> (a1 -> a1) -> [a2] -> t
        Actual: (a0 -> b0) -> [a0] -> [b0]
    • In the first argument of ‘sum’, namely ‘map’
      In the expression: sum map (+ 1) [1, 2, 3]

In your example the compiler expected (a0 -> b0) -> (a1 -> a1) -> [a2] -> t, whereas in my example it expected a0 -> (a1 -> a1) -> [a2] -> t. So was the compiler expecting different things?! Are those types truly different?

(a0 -> b0) -> (a1 -> a1) -> [a2] -> t
a0         -> (a1 -> a1) -> [a2] -> t

No, it's just that the former is restricted to take a first argument of type a0 -> b0, i.e. a function, whereas the latter can accept any a0, i.e. functions plus non functions.

And that's a consequence of the fact that you you passed map which is a less generic type, (a -> b) -> [a] -> [b], and I passed (:) which is a bit more generic, a -> [a] -> [a], so the former ended up constraining the expected signature of the first argument to sum a bit more, i.e. (a0 -> b0) instead of a0.