Why does this code require the Monad constraint?

Question

While building a monad stack with monad transformers to write a library, I hit a question about the behavior of it.

The following code won't pass the type checker:

{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module Foo (FooM, runFooM, foo) where

import Control.Applicative
import Control.Monad.Reader

newtype FooM m a = FooM { runFooM :: ReaderT Int m a }
  deriving (Functor, Applicative, Monad, MonadReader Int)

foo :: FooM m Int
foo = do
  x <- ask
  return x

The error is:

$ ghc foo.hs
[1 of 1] Compiling Foo              ( foo.hs, foo.o )

foo.hs:12:3:
    No instance for (Monad m) arising from a do statement
    Possible fix:
      add (Monad m) to the context of
        the type signature for foo :: FooM m Int
    In a stmt of a 'do' block: x <- ask
    In the expression:
      do { x <- ask;
           return x }
    In an equation for ‘foo’:
        foo
          = do { x <- ask;
                 return x }

The fix is easy as GHC suggests, just adds Monad constraint to the foo function:

foo :: Monad m => FooM m Int
foo = do
  x <- ask
  return x

But here, the foo function only asks the FooM value to give its Int value and it is already an (automatically derived) MonadReader instance. So I think Monad constraint is not required to m.

I guess this relates to the implementation of the monad transformers (I use mlt==2.2.1), but I cannot figure out the exact reason. I may miss something obvious though. Could you explain why this doesn't pass the checker?

Thanks.

shang shang · Accepted Answer · 2014-08-29T11:37:46

It's because the Monad instance for ReaderT is defined as

instance Monad m => Monad (ReaderT r m)

i.e. the type ReaderT r m is an instance of Monad only if the inne rm is an instance of Monad. That's why you cannot have an unconstrained m when using the Monad instance of ReaderT (which your FooM type is using via the deriving mechanism).

Why does this code require the Monad constraint?

3 Answers