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

I'm +1 on whenM and unlessM - those I have wanted and think are very worthwhile. Regardless of the naming convention stuff (which I have never even been aware of in my day-to-day coding with Haskell), I think these are the right names, and they also match the naming with monad-loops (`whileM`, etc). I'd be -1 on mwhen, munless, etc. I'm +/-0 on ifM, but that doesn't seem to be in the original proposal anyway. I can see the value in it, but I've never really needed it. I would probably use f >>= bool x y in practice. - ocharles On Mon, Apr 21, 2014 at 7:34 PM, Brandon Allbery wrote:

On Mon, Apr 21, 2014 at 2:26 PM, Evan Laforge wrote:

...

On Mon, Apr 21, 2014 at 11:19 AM, Bardur Arantsson wrote:

...

On 2014-04-21 17:47, Edward Kmett wrote:

...

I, for one, could get behind just taking ifM, whenM, unlessM for these operations, proper naming conventions aside.

They've been independently reinvented in 60+ packages with these exact names.

If we do this, over time we'll save another 60+ packages the trouble of doing the same thing.

+1 (for the proposal, based on exactly the above summary)

+1 from me too, because I have the same functions with these names in my non-cabal packages.

There might be a lot of non-cabal whenM etc. out there.

And you're still missing a few with more specific type signatures, e.g. xmonad's whenX.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries