In opposition of Functor as super-class of Monad

Conor McBride conor at strictlypositive.org
Tue Jan 4 14:57:39 CET 2011


Hi folks

I think we should wait until we've thought about superclass methods
defaults before we decide whether Functor should be a superclass
of Monad, as it clearly has significant impact on the cost-benefit
analysis of the change, and also the details of it. But as I
mentioned in my other recent message, I'd rather hope that doesn't
mean kicking the whole thing into the long grass.

So, as Dan and Martijn point out:

On 4 Jan 2011, at 13:29, Dan Doel wrote:

> As for the other concerns, I think the closest fix I've seen is to  
> allow
> subclasses to specify defaults for superclasses, and allow instances  
> for
> subclasses to include methods for superclasses. So:
>
>  class Functor m => Monad m where
>    return :: a -> m a
>    (>>=)  :: m a -> (a -> m b) -> m b
>
>    fmap f x = x >>= return . f

modulo other considerations treated elsewhere, gives

>  instance Monad m => Functor (Iterate el m) where ...

Now, Oleg rightly points out that one can have

    instance Functor m => Functor (Iteratee el m)

at the cost of code duplication. However, this is not such a strong
objection because either

   (a) the overconstrained Functor-from-Monad definition is sufficient,
         in which case we're talking at most a 2-line penalty,
         although 0 would be nice;
   (b) preservation of functoriality is specifically desired,
         in which case the duplication problem is no worse than it is
         at present.

Oleg's example does raise a serious concern about structure-preserving
*transformers* in general. There is a missing abstraction. The same
issue arises with monad and applicative transformers. It's hard to
say `you can get out the structure you put in'. Perhaps there's a way
to express these things as arrow-transformers, working for any notion
of arrow with sufficient structure.

To sum up, the code duplication problem Oleg raises is a serious
concern in any case, but it has little or no impact on the issue at
hand.

All the best

Conor




More information about the Haskell-prime mailing list