On Sat, Jan 03, 2015 at 03:31:29PM -0500, David Feuer wrote:
http://stackoverflow.com/questions/22750315/ applicative-instance-for-maybet-m-assumes-monad-m noted that
instance (Functor m, Monad m) => Applicative (MaybeT m) instance (Functor m, Monad m) => Alternative (MaybeT m)
is not exactly ideal. An answer to the question explained why MaybeT isn't really so important for Applicative, but that doesn't seem to be a good reason to leave the status quo in place. If I'm not very much mistaken, there are two issues:
1. The Functor constraint is never used, and of course every valid monad is also a valid functor with fmap=liftM. So for pre-AMP base, the signatures should have had only a Monad constraint, and not a Functor one.
I guess the unused Functor constraint might as well be dropped -- it will be redundant in the AMP world anyway.
2. For AMP, the constraints should be changed to require Applicative instead of Monad.
This instance will still require Monad even if Applicative is a superclass. We expect that applicatives that are also monads will satisfy (<*>) = ap (though sometimes (<*>) will be more efficient, it should be semantically equivalent). Since ap doesn't execute the second action if the first one fails, this requires that the inner constructor is a monad. (The instance proposed at the above link doesn't meet this expectation; it is equivalent to Errors ().)