cascading type errors in ghc

[Evan Laforge]

I frequently see one logical mistake turn into many type errors in
ghc.  Of course in general "one logical mistake" to a human and a type
checker can be completely different things, so that's not surprising.
The thing is, I feel like I started seeing more with the upgrade to
ghc 7.6 (or was it 7.4?) a while back, which I guess coincides with a
big typechecker overhaul.  So I tracked down a specific example,
though I haven't checked if this gives different results in older
ghcs:

complicated :: Bool -> Int -> (Double -> Double)
    -> Int -> Char -> Int -> Char -> ()
complicated _ _ _ _ _ _ _ = ()

t0 = complicated 0 id x1 y1 x1 y1
    where
    x1 :: Int
    x1 = 0
    y1 :: Char
    y1 = 'a'

In this case, the call to complicated is missing the initial Bool.  In
ghci the above gives 5 separate type errors, for the 2nd, 3rd, 4th,
5th, and 6th arguments.  The curious thing is, if I replace x1 and y1
with their values:

t0 = complicated 0 id 0 'a' 0 'a'

I'm now down to only 3 type errors, for 2nd, 4th, and 6th args.

So I'm just curious: what's the difference between the where-bound
stuff and literals?  Also, why don't I get an error that 0 isn't a
Bool?  Or I suppose, that there's no instance Integral Bool?