Proposal: add ifM and whenM to Control.Monad

[Edward Kmett]

I still don't like 'om', naming aside.

ifM, whenM and unlessM are at least something folks expect to find, so
supplying names for those things that people actually go looking for is one
thing. They are repeatedly reinvented using exactly those names, so I can
see just adding them where people expect to find them, if only so we can
stop repeating this conversation every 6 months.

They are also at least a bit of a composition, so they aren't just a
trivial restriction of another combinator with broader range of
applicability, that we'd like users to learn how to use in its full
generality.

On the other hand supplying something like 'om' is awkward to motivate is
isolation.

It happens to munge a monad on one arg but not the other in a weird special
case just because it happens to unify here. But that doesn't give any real
insight to the user and forces them into a mode where they just have to
memorize that this modifier only works in these couple of cases. 'om'
doesn't really abstract over anything fundamental.

One can't explain why anyone would care about it without reference to the
quirks of two other function signatures.

-Edward


On Sun, Apr 20, 2014 at 5:10 PM, John Wiegley <johnw at newartisans.com> wrote:

> >>>>> Edward Kmett <ekmett at gmail.com> writes:
>
> > However, given that they keep getting reinvented with the exact same
> names
> > and functionality. I'm finally ready to give in.
>
> > +1 from me.
>
> How about a more general combinator, like om (name needed)?
>
>     om :: Monad m => (a -> b -> m c) -> m a -> b -> m c
>     om f m = (m >>=) . flip f
>
> whenM = om when
> unlessM = om unless
>
> etc.
>
> John
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140420/2de3f544/attachment.html>