Applicative and Functor

Ross Paterson ross at soi.city.ac.uk
Sun Mar 5 18:34:14 EST 2006


On Sun, Mar 05, 2006 at 12:46:57AM -0800, Ashley Yakeley 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]
> 
> 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'm almost convinced.  There's one small technical problem: I have

	instance Applicative ((->) a)

so I would also need

	instance Functor ((->) a)

but where should it go?  (The same instance occurs in
Control.Monad.Reader, but that could be removed.)

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

Do you have both instances and clients for this interface?  And can an
associativity law even be stated?

Functor+return is sometimes seen, under the names "premonad" or
"pointed functor".

> <http://haskell.org/haskellwiki/Functor_hierarchy_proposal>
> 
> 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.

Then I imagine you'll be similarly offended by Traversable not having
Functor and Foldable as superclasses.



More information about the Libraries mailing list