In opposition of Functor as super-class of Monad

[Martijn van Steenbergen]

Method C: Define fmap in terms of bind

> instance Monad m => Functor (Iteratee el m) where
>   fmap = liftM

Now you need to do the inspection of Iteratee only once: in the 
definition of the bind. However, to use liftM as implementation of fmap 
the superclass constraint of the Functor instance has changed from 
Functor to Monad.

Is this a problem? If so, method A seems the way to go: you could argue 
that `Functor m => fmap :: (a -> b) -> Iteratee el m a -> Iteratee el m 
b' is more general than the `Monad m =>' version (works for more `m's) 
and therefore deserves to redo the analysis of Iteratee.

Martijn.


On 1/4/11 11:24, oleg at okmij.org wrote:
> I'd like to argue in opposition of making Functor a super-class of
> Monad. I would argue that superclass constraints are not the right
> tool for expressing mathematical relationship such that all monads are
> functors and applicatives.