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