In opposition of Functor as super-class of Monad
S. Doaitse Swierstra
doaitse at swierstra.net
Wed Jan 5 10:01:17 CET 2011
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
More information about the Haskell-prime
mailing list