#50: Does `Applicative (MaybeT m)` really need the `Monad` constraint?

concrete functor and monad transformers

#50Does `Applicative (MaybeT m)` really need the `Monad` constraint?

Basically, instead of the existing Applicative implementation for MaybeT that relies on >>= and return, I think it could be defined as such:

instance (Applicative m) => Applicative (MaybeT m) where
    pure = MaybeT . pure . Just
    mf <*> mx = let f = fmap (<*>) (runMaybeT mf) in MaybeT $ f <*> runMaybeT mx

I think the same goes for a few others as well (eg, EitherT). But perhaps there is some good reason for using bind/Monad instead?

beark Mon Feb 12 07:14:27 UTC 2018
- description updated
Ross Paterson Mon Feb 12 17:32:35 UTC 2018
The issue is that when an Applicative is also a Monad, (<*>) needs to be the same as ap. With the monadic version, if the first argument yields Nothing, the second second is not executed, whereas with the above version it would be.
beark Tue Feb 13 01:16:29 UTC 2018
Ah, right, that makes perfect sense. Thanks for the explanation!
Ross Paterson Tue Feb 13 01:29:25 UTC 2018
- status set to closed

hub.darcs.net :: ross -> transformers -> issue

#50Does `Applicative (MaybeT m)` really need the `Monad` constraint?