[GHC] #7856: Wrong error message for unknown Instance

[GHC]

#7856: Wrong error message for unknown Instance
----------------------------------------+-----------------------------------
    Reporter:  bas                      |       Owner:                                   
        Type:  feature request          |      Status:  new                              
    Priority:  normal                   |   Milestone:  _|_                              
   Component:  Compiler (Type checker)  |     Version:  7.6.3                            
    Keywords:  Instance                 |          Os:  Unknown/Multiple                 
Architecture:  Unknown/Multiple         |     Failure:  Incorrect warning at compile-time
  Difficulty:  Unknown                  |    Testcase:                                   
   Blockedby:                           |    Blocking:                                   
     Related:                           |  
----------------------------------------+-----------------------------------
Changes (by simonpj):

  * difficulty:  => Unknown
  * milestone:  => _|_


Comment:

 Here is what is happening.  We typecheck this definition
 {{{
 tmp :: String -> IO ()
 tmp = sequence_ lst
   where lst = [putStrLn "hi"]
 }}}
 Remember that `sequence_ :: Monad m => [m a] -> m ()`.  So GHC generates
 two type equalities:
 {{{
 (1)    m () ~ (->) String (IO ())   -- From the return type of (sequence_
 lst)
 (2)    m a  ~ IO ()                 -- From the argument of _sequence
 }}}
 If GHC solved (2) first (by `m:=IO, a:=()`), all would be well.  But it
 happens to try to solve (1) first, by decomposing into
 {{{
 (1a)   m ~ (->) String
 (1b)   () ~ IO ()
 }}}
 And it is (1b) that is reported as an error.  In reporting the error GHC
 says where it came from, namely from (1), that is unifying `m () ~ String
 -> IO ()`.  But by that time GHC has solved (1b) by `m:=(->) String`, so
 the error is reported as a mismatch between `String -> ()` and `String ->
 IO ()`.

 So that's the reason. And I don't see an easy way to improve matters.
 Maybe we should somehow seek to prioritise (2) over (1), but how?

 Nice example.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7856#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler