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