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
+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