Giving good type error messages is tricky!

You get different behaviour for literals because 0 has type (forall a. Num a => 
a), whereas you declared x1 to have type Int.  GHC could have additionally said 
"Can't find an instance for Num Bool, but it suppresses such errors if there 
are more serious ones at hand.  Hence the difference you observed.

Previous GHCs would often bale out altogether if they tried to unify Int with 
Bool, and recover at some outer point.  That's good for not getting lots of 
errors, but it might suppress genuinely separate errors.  Nowadays we gather 
all the unsolved constraints without an exception-style bale-out, which 
probably accounts for you seeing more errors.

The good news is that error generation is all in one module TcErrors.lhs, so 
it's easy to adjust these things.  For example, given a nearby bunch of errors, 
you could suppress all but one.  I don't know whether that would on balance 
make things better or not.  But it's certainly easy to experiment (if you build 
yourself a GHC).

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org]
|  On Behalf Of Evan Laforge
|  Sent: 27 July 2013 20:36
|  To: GHC users
|  Subject: cascading type errors in ghc
|  
|  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?
|  
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to