Upgrade MaybeT to AMP, and otherwise clean it up

[Ross Paterson]

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 ().)