On 4 jan 2011, at 11:24, oleg@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.
It _almost_ makes me wish the constraint go the other way:
instance Monad m => Functor m where fmap f m = m >>= (return . f)
That is, we need an instance rather than a superclass constraint, and in the other direction. The instance constraint says that every monad is a functor. Moreover, \f m = m >>= (return . f)
is a _proof term_ that every monad is a functor. We can state it once and for all, for all present and future monads.
Alas, the instance ``instance Monad m => Functor m'' above has several drawbacks (for one, requiring overlapping instances everywhere). This makes me wonder if something is amiss.
The only real use I have ever seen of using superclasses is to be able to give default definitions which can be overridden with more efficient versions where needed, so here I would have expected: class Monad m => Functor m where fmap f m = >>= (return . f) Doaitse
In the meanwhile, there is a practical work-around. Introduce a TemplateHaskell operation generating an instance such as
instance Monad (Iteratee el m) => Functor (Iteratee el m) where fmap f m = m >>= (return . f)
(the code for the method remains the same; only the type in the instance head varies). Alas, that requires undecidable instances. All the code before was Haskell98.
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime