
On Tue, 24 Jun 2008, Malcolm Wallace wrote:
Ashley Yakeley
wrote: Make Applicative (in Control.Applicative) a superclass of Monad (in Control.Monad).
I'm strongly against.
Some datatypes have several different possible implementations of Applicative, for instance, they may be either lazy or strict. The PolyParse library relies crucially on the fact that the Monad and Applicative instances for the Parser type have different strictness behaviours.
I worry that if Applicative were to become a superclass of Monad, this way of partitioning my API into lazy and strict portions may no longer be possible, or least, a good deal less convenient.
Although I also see no compatible way to make Applicative a superclass of Monad, I think it should be so. Intuitively it is a superclass and it would surprise me if a library has inconsistent instances of Applicative and Monad. So I count your example as argument _for_ making Applicative a superclass of Monad in order to reduce the risk of surprises for the library user.