In opposition of Functor as super-class of Monad

[S. Doaitse Swierstra]

On 4 jan 2011, at 11:24, oleg at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime