#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