Applicative and Functor

Ashley Yakeley ashley at
Sun Mar 5 03:46:57 EST 2006

In article <20060304095543.GA3772 at>,
 Ross Paterson <ross at> wrote:

> On Fri, Mar 03, 2006 at 07:14:16PM -0800, Ashley Yakeley wrote:
> > Shouldn't Applicative be a subclass of Functor? "<$>" can then be dropped.
> > [The Functor laws are implied by the Applicative laws]
> It's the same old problem as with Monad, Functor and liftM (or indeed
> with Monad, Applicative and return): that fine-grained hierarchies in
> Haskell mean extra work for the programmer.  You'd be forced to define a
> Functor instance, even if all you wanted was pure and <*>.  There have
> been a series of proposed language changes to address this, the latest
> being John Meacham's class synonyms.  But less connected classes seem
> to fit better with the current Haskell.

I think it was particularly the wrong decision for Applicative, since 
Functor is the more commonly used class. Types declared Applicative and 
not Functor must be rare: surely this is not worth the burden of 
multiple symbols meaning the same thing.

I don't really approve of the decision for Monad, but Monad is very 
commonly used. I consider the separation a thorn.

There may also be a case for a class with ap (<*>) but not return 
(pure), which might better be called "Applicative". I would have gone 
for this:

  class Functor f where
    fmap :: (a -> b) -> f a -> f b

  class (Functor f) => Applicative where
    ap :: f (a -> b) -> f a -> f b

  class (Applicative f) => Idiom f where
    return :: a -> f a

  class (Idiom f) => Monad f where
    (>>=) :: f a -> (a -> f b) -> f b
    (>>) :: f a -> f b -> f b
    fa >> fb = fa >>= (const fb)

But I could be wrong, there may be no great use for ap without return.

I do agree with you that a mechanism for automatically declaring 
superclass instances, or somesuch, would be helpful. But I prefer the 
purity and correctness of a hierarchy anyway, even if it means extra 
work for the programmer.

Ashley Yakeley, Seattle WA

More information about the Libraries mailing list