Re: Proposal: add ifM and whenM to Control.Monad

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 wrote:

...

...

...

...

...

Edward Kmett 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries