Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

Um (-1)... This just looks like a synthetic combinator to me (cue the arbitrary name). Naturally it can make some code shorter (that's the point of combinators) but I have reservations that the code is significantly clearer, more appealing.

Stephen Tetley
writes:
This just looks like a synthetic combinator to me (cue the arbitrary name). Naturally it can make some code shorter (that's the point of combinators) but I have reservations that the code is significantly clearer, more appealing.
It's just that I tend to write the following a LOT: x <- someMonadicFunction when x $ do ... I generally avoid using whenM because it seems silly to bring in a package dependency for something so trivial. With "om", it's the same thing: om when someMonadicFunction $ do ... I really didn't think it was that confusing or hard to read, but if people dislike it on principle, I have no other arguments besides utility. I find myself reaching for it a lot, so thought others might too. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

On Thu, Jul 25, 2013 at 9:37 PM, John Wiegley
It's just that I tend to write the following a LOT:
x <- someMonadicFunction when x $ do
Sure, this is a common pattern. But the name is terrible, and it's not clear to me that the functionality is a useful generalization. Why not advocate for whenM instead? whenM :: Monad m => m Bool -> m () -> m ()

Bryan O'Sullivan
writes:
Sure, this is a common pattern. But the name is terrible, and it's not clear to me that the functionality is a useful generalization. Why not advocate for whenM instead?
whenM :: Monad m => m Bool -> m () -> m ()
The entire point of the proposal is that "om" subsumes such specialized functions, saving you from having to use whenM, unlessM, etc. You simply put "om" (or whatever name you want to call it, the name wasn't the objective of this proposal) in front of functions you already know and use, and suddenly they become able to accept monadic arguments where they couldn't before. Consider the "om forM_" example from before, which is actually quite handy and clarifying, once you know how to read the combinator. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net
participants (3)
-
Bryan O'Sullivan
-
John Wiegley
-
Stephen Tetley