Proposal: function from Maybe to Alternative

[Li-yao Xia]

Hello Libraries,

I previously proposed adding a `liftMaybe :: Applicative m => Maybe a -> 
MaybeT m a` to transformers, on its issue tracker [1]. But its 
generalization to `Alternative m => Maybe a -> m a` seems like a nice 
addition to the base library, inside `Control.Applicative` (or 
`Data.Maybe`).

My proposal is the following:

1) In base, add `liftMaybe = maybe empty pure :: Alternative m => Maybe 
a -> m a` to `Control.Applicative`.

2) In transformers, reexport it from `Control.Monad.Trans.Maybe`.

There was another thread [2] on this ML also about the same combinator, 
and the main question appears to be whether it crosses the Fairbairn 
threshold. I can give some more arguments.

I think it's worth giving it a name, even if there is a three-word 
definition (`liftMaybe = maybe empty pure`). I've found myself looking 
for it a few times, and that short definition is the result of a bit of 
code-golfing that not everyone is familiar with. Some may end up with 
more verbose reimplementations instead.

Its absence stands out even more, as it is also the MaybeT counterpart 
to the functions `except`, `state`, `reader`, etc. which exist for other 
monad transformers.

A few minor remarks.

There is some asymmetry with the solution as I proposed it: this one 
function `liftMaybe` would correspond to two functions for every other 
transformer, one in the transformers library (`except`, `state`, etc.), 
one in mtl (`liftEither`, `state`, etc.). In contrast, the mtl-style 
class associated with `MaybeT` is `Alternative`. Since it is part of the 
standard library, it's not as useful to define a specialized version in 
`Control.Monad.Trans.Maybe` as it is for the other transformers. If we 
still decide to add a specialized function, a slightly lazier 
implementation is possible:

liftMaybe :: Applicative m => Maybe a -> MaybeT m a
liftMaybe = MaybeT . pure

Cheers,
Li-yao


[1] https://hub.darcs.net/ross/transformers/issue/49
[2] https://mail.haskell.org/pipermail/libraries/2012-February/017548.html