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