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