On 4 jan 2011, at 11:24, o...@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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime