Proposal: add ifM and whenM to Control.Monad

[Greg Weber]

I don't understand how the existing naming convention for promoting
functions to monadic versions can apply to when/unless since they already
operate on monads.

I would hesitate to use an 'm' prefix for monadic code is because the
Monoid typeclass does that (mempty, mappend, mconcat).
I would support a change in the documented convention for the 'm' prefix to
only being used for MonadPlus (in addition to Monoid).

+1 on  whenM and unlessM

I haven't found myself needing ifM, but I will look at my code and see if I
was missing opportunities to make it nicer.


On Sun, Apr 20, 2014 at 4:22 PM, wren romano <winterkoninkje at gmail.com>wrote:

> +1 for finally adding ifM, whenM, and unlessM to Control.Monad (what
> about guardM?)
>
> As far as bike-shedding goes, the naming-convention abiding mif,
> mwhen, and munless are also fine— albeit they look a bit strange.
> While the official fooM vs mfoo convention is spelled out in
> Control.Monad, I don't know how much anyone actually pays attention to
> that; a lot of people use the fooM pattern ubiquitously instead. In
> practice the mfoo pattern is only used with mzero, mplus, msum, and
> mfilter— so in practice it seems more like "mfoo means the MonadPlus
> variant of foo" whereas "fooM means the Monad variant of foo".
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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/517d8d9a/attachment.html>