In article <20060304095543.GA3772@soi.city.ac.uk>,
Ross Paterson
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. 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. -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/