Re: Proposal: add ifM and whenM to Control.Monad

Thank you. So bool takes the predicate as last argument, good for combining it with a monadic operation: doesDirectoryExists path >>= bool (putStrLn ("Creating dir " ++ path) >> createDirectory path) (putStrLn ("Directory already exists")) I still prefer the version using mif/ifM, in particular when working with IO: ifM (doesDirectoryExists path) (putStrLn ("Directory already exists")) (putStrLn ("Creating dir " ++ path) >> createDirectory path) On 04/21/2014 02:16 PM, Edward Kmett wrote:

http://hackage.haskell.org/package/base-4.7.0.0/docs/src/Data-Bool.html#bool

On Mon, Apr 21, 2014 at 5:35 AM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

On 04/21/2014 10:41 AM, Simon Hengel wrote:

A quick heuristic grep over all Hackage packages results in quite a bit of packages containing the ifM/whenM/unlessM:

But that kind of shows that the "expected" names for those functions are ifM/whenM/unlessM. I would ask the question:

Are there any other useful combinators that would be named ifM/whenM/unlessM under the current naming convention?

If no, then I'm not entirely convinced that we should decide against what seems to be common intuition here.

Breaking API consistency because a lot of people are already doing it doesn't feel right. If they are like me, they probably were ignoring the naming convention and used the most intuitive name. Once you know forM then it's obvious that you append 'M' to functions that "are more monadic". Probably mif, mwhen and munless are more compatible with the API rules.

In general, I'm not sure about ifM (as it does not line up with `bool`).

This is the second time that I read about `bool` but I can't find it. Can somebody provide a link to it? mbool can be a solution, but not as intuitive as mif.

Mario