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.