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