Li-yao Xia
2018-04-01 22:09:08 UTC
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
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