Proposal: add ifM and whenM to Control.Monad

[Daniel Trstenjak]

On Mon, Apr 21, 2014 at 09:49:40AM +0200, Herbert Valerio Riedel wrote:
> I'm +1 on using `mif`/`mwhen`/`munless` (assuming all those pass the
> current naming convention), because otherwise adding an exception to the
> naming convention for Control.Monad entities would also require
> rewording the existing naming convention in the Haskell Report.

I just think that these names read horrible and also if the name 'whenM'
doesn't perfectly fit into the naming convention, because 'when' already
operates on Monads, nevertheless a lot of people name it 'whenM' when
they need exactly this functionality, so the name doesn't seem to be
completely off.

But I don't think that mif/mwhen/munless is a better fit for the current
naming convention, because a prefixed 'm' is mostly only used for
methods of type classes.

> Moreover, since 'Control.Monad' is often imported unqualified, we'd
> probably cause clashes in existing packages (and together with non-PVP
> upper-bounds on base that'd mean build failures)
> 
> A quick heuristic grep over all Hackage packages results in quite a bit
> of packages containing the ifM/whenM/unlessM:

These are certainly some valid points, but then I wouldn't add any new
functions at all, before adding some having IMHO bad names.

So I'm +1 for whenM/unlessM, but I'm not sure for IfM, because it might
result into harder to read code if the 'if' and 'else' branches get
longer and you have no visual hint to separate the two.


Greetings,
Daniel