On 2014-04-21 at 09:49:40 +0200, Herbert Valerio Riedel wrote:
On 2014-04-21 at 00:35:03 +0200, Edward Kmett wrote:
mif appears to pass the naming convention rules. It looks strange, but we can chalk that up to lack of exposure.
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.
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:
All that said, I'm (also) +1 the ifM/whenM/unlessM variants, under the condition that - somebody comes up with an amended wording for Haskell Report 2010's "13.2.1 Naming conventions"[3] section that avoids the inconsistency, and - somebody takes care to inform/pester/annoy the maintainers of the 70+ package that to make sure that those packages aren't left broken (if they break) for long after this gets merged into GHC HEAD [1][2] [1]: The motivation for this being, that I'd like people to be able to use nightlies of GHC HEAD, e.g. via Travis-CI to test their packages' 'master' branch early for potential GHC HEAD breakages (and report those to GHC HQ if it looks like a GHC bug), this however is thwarted if the builds start failing due to build-deps being broken. [2]: Ironically, the easiest way to fix packages (w/o breaking compat for base<4.7.1) would be to simply make sure the new ifM/whenM functions are not imported, and that the package-local hand-rolled versions of ifM/whenM are continued to be used... [3]: http://www.haskell.org/onlinereport/haskell2010/haskellch13.html#x21-1950001...