Functor instance of ReaderT

The Functor instance of ReaderT has the header: Monad m => Functor (ReaderT r m) I thought (Functor m) must be the appropriate constraint.

On Tue, Aug 5, 2008 at 2:19 PM, Henning Thielemann
The Functor instance of ReaderT has the header: Monad m => Functor (ReaderT r m)
I thought (Functor m) must be the appropriate constraint.
Note that there *is* an advantage to having Monad as the context: not every monad implements Functor, even though it could. So having Functor as the context isn't *trivially* superior. Taking this into consideration, and taking into consideration that ReaderT is usually thought of as related to monads (e.g., it's in Control.Monad.Reader), I'm not sure that the preferred way of transforming a functor wouldn't be (r ->) :.: f where :.: is functor composition. But then, functor composition apparently isn't actually in the library, which surprised me (it's in the applicative functor paper, but not in Control.Applicative), so maybe changing ReaderT to be usable with functors is more warranted. Or perhaps adding functor composition is the way to go? All the best, - Benja

On Tue, 5 Aug 2008, Benja Fallenstein wrote:
On Tue, Aug 5, 2008 at 2:19 PM, Henning Thielemann
wrote: The Functor instance of ReaderT has the header: Monad m => Functor (ReaderT r m)
I thought (Functor m) must be the appropriate constraint.
Note that there *is* an advantage to having Monad as the context: not every monad implements Functor, even though it could. So having Functor as the context isn't *trivially* superior.
I know, but if a Monad instance exists, then the Functor instance can be simply added, whereas when the opposite direction is not always possible. So, lifting the constraint from Monad to Functor can break existing packages, but the problems are "easy to fix" (TM). :-)
participants (2)
-
Benja Fallenstein
-
Henning Thielemann