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