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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
