Applicative and Functor
ashley at semantic.org
Sun Mar 5 03:46:57 EST 2006
In article <20060304095543.GA3772 at soi.city.ac.uk>,
Ross Paterson <ross at soi.city.ac.uk> 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
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