[GHC] #10351: Inferred type is rejected

[GHC]

#10351: Inferred type is rejected
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                   Owner:
            Type:  bug               |                  Status:  closed
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.1
      Resolution:  fixed             |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |  typecheck/should_fail/T10351
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by darchon):

 I don't know if this ticket should be re-opened or not, but I do want to
 note the following.

 I was compiling the `tasty` package
 (http://hackage.haskell.org/package/tasty) with `ghc-7.11.20150505` and
 got the following error:
 {{{
 [11 of 17] Compiling Test.Tasty.Ingredients.ConsoleReporter (
 Test/Tasty/Ingredients/ConsoleReporter.hs, dist/dist-sandbox-
 4347b07a/build/Test/Tasty/Ingredients/ConsoleReporter.o )

 Test/Tasty/Ingredients/ConsoleReporter.hs:124:11: error:
     Could not deduce (MonadState IntMap.Key f)
       arising from a use of ‘get’
     from the context: (?colors::Bool, Monoid b)
       bound by the type signature for:
                foldTestOutput :: (?colors::Bool, Monoid b) =>
                                  (IO () -> IO Result -> (Result -> IO ())
 -> b)
                                  -> (IO () -> b -> b) -> TestOutput ->
 StatusMap -> b
       at Test/Tasty/Ingredients/ConsoleReporter.hs:(117,6)-(120,33)
     or from: Monad f
       bound by the inferred type of go :: Monad f => TestOutput -> Ap f b
       at Test/Tasty/Ingredients/ConsoleReporter.hs:(123,3)-(135,18)
     In a stmt of a 'do' block: ix <- get
     In the second argument of ‘($)’, namely
       ‘do { ix <- get;
             put $! ix + 1;
             let statusVar
                   = fromMaybe (error "internal error: index out of
 bounds")
                     $ IntMap.lookup ix smap
                 readStatusVar = getResultFromTVar statusVar;
             return $ foldTest printName readStatusVar printResult }’
     In the expression:
       Ap
       $ do { ix <- get;
              put $! ix + 1;
              let statusVar
                    = fromMaybe (error "internal error: index out of
 bounds")
                      $ IntMap.lookup ix smap
                  readStatusVar = getResultFromTVar statusVar;
              return $ foldTest printName readStatusVar printResult }
 }}}

 Where this reported
 {{{
 go :: Mond f => TestOutput -> Ap f b
 }}}
 function is defined within a `where` clause.
 With the behaviour as implemented in the above patch, I first had to
 annotate `go` in the code as:

 {{{
 go :: MonadState IntMap.Key f => TestOutput -> Ap f b
 }}}

 And only then GHC would inform me that I needed to enable
 `FlexibleContexts`.
 However, if the behaviour was still as it was as reported in the ticket,
 pre-patch, GHC would have informed me immediately that I should have
 enabled `FlexibleContexts`. Or do I misunderstand the intention of the
 patch?

 I don't know if it is a bad (and/or common) programming practice to add as
 many `LANGUAGE` pragma's as GHC tells you to until your code starts
 compiling. But I know the above patch certainly hinders that practice.

 Perhaps a separate issue: I don't understand why the `tasty` package
 compiled on GHC 7.10.1 in the first place, but started failing in HEAD.

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