+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

I still don't like 'om', naming aside. ifM, whenM and unlessM are at least something folks expect to find, so supplying names for those things that people actually go looking for is one thing. They are repeatedly reinvented using exactly those names, so I can see just adding them where people expect to find them, if only so we can stop repeating this conversation every 6 months. They are also at least a bit of a composition, so they aren't just a trivial restriction of another combinator with broader range of applicability, that we'd like users to learn how to use in its full generality. On the other hand supplying something like 'om' is awkward to motivate is isolation. It happens to munge a monad on one arg but not the other in a weird special case just because it happens to unify here. But that doesn't give any real insight to the user and forces them into a mode where they just have to memorize that this modifier only works in these couple of cases. 'om' doesn't really abstract over anything fundamental. One can't explain why anyone would care about it without reference to the quirks of two other function signatures. -Edward On Sun, Apr 20, 2014 at 5:10 PM, John Wiegley wrote:

...

...

...

...

...

Edward Kmett writes:

...

However, given that they keep getting reinvented with the exact same names and functionality. I'm finally ready to give in.

...

+1 from me.

How about a more general combinator, like om (name needed)?

om :: Monad m => (a -> b -> m c) -> m a -> b -> m c om f m = (m >>=) . flip f

whenM = om when unlessM = om unless

etc.

John _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

The principled objection to giving these combinators the "obvious" names in Control.Monad is that that module has historically held to a detailed convention that these proposed names unfortunately don't fit. =/ The functions in this library use the following naming conventions:

- A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example,

filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

- A postfix '_' changes the result type from (m a) to (m ()). Thus, for example:

sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m ()

- A prefix 'm' generalizes an existing function to a monadic form. Thus, for example:

sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a

That said, if we do adopt them, they probably should get the ifM, whenM, unlessM names. I don't think the convention has been documented in Control.Monad itself for years. -Edward On Sun, Apr 20, 2014 at 4:26 PM, Mario Pastorelli < pastorelli.mario@gmail.com> wrote:

Hi Herbert,

in general I like pattern matching but not when boolean values are involved. Your code is nice but, in my opinion, still far from the elegance of

f = unlessM (doesDirectoryExist path) $ do

putStrLn $ "Creating directory " ++ path createDirectory path

In particular, note that I don't have to take care of the False case and the code doesn't have boilerplate.

While your solution is more general, I would like to point out that when and unless are so useful that they got their own functions in the library instead of relying on pattern matching. I consider ifM, whenM and unlessM as alternate versions of existing functions.

On 04/20/2014 09:59 PM, Herbert Valerio Riedel wrote:

...

Hi Mario,

On 2014-04-20 at 21:10:03 +0200, Mario Pastorelli wrote:

...

I would like to propose the addition of two new combinators to Control.Monad:

ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m ()

[...]

f = do

...

dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path

While I'm neutral on this proposal, I'd like to remind that LambdaCase may be useful to avoid temporary variables as well (and is even more useful for types other than Bool):

f = doesDirectoryExist path >>= \case True -> return () False -> do putStrLn $ "Creating directory " ++ path createDirectory path Cheers, hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I see. Another solution is to use if', when' and unless'. On 04/20/2014 11:42 PM, Edward Kmett wrote:

My mistake. These rules are still in Control.Monad. I just scrolled right past them.

-Edward

On Sun, Apr 20, 2014 at 5:04 PM, Edward Kmett mailto:ekmett@gmail.com> wrote:

The principled objection to giving these combinators the "obvious" names in Control.Monad is that that module has historically held to a detailed convention that these proposed names unfortunately don't fit. =/

The functions in this library use the following naming conventions:

* A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example,

filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

* A postfix '_' changes the result type from (m a) to (m ()). Thus, for example:

sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m ()

* A prefix 'm' generalizes an existing function to a monadic form. Thus, for example:

sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a

That said, if we do adopt them, they probably should get the ifM, whenM, unlessM names.

I don't think the convention has been documented in Control.Monad itself for years.

-Edward

On Sun, Apr 20, 2014 at 4:26 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

Hi Herbert,

in general I like pattern matching but not when boolean values are involved. Your code is nice but, in my opinion, still far from the elegance of

f = unlessM (doesDirectoryExist path) $ do

putStrLn $ "Creating directory " ++ path createDirectory path

In particular, note that I don't have to take care of the False case and the code doesn't have boilerplate.

While your solution is more general, I would like to point out that when and unless are so useful that they got their own functions in the library instead of relying on pattern matching. I consider ifM, whenM and unlessM as alternate versions of existing functions.

On 04/20/2014 09:59 PM, Herbert Valerio Riedel wrote:

Hi Mario,

On 2014-04-20 at 21:10:03 +0200, Mario Pastorelli wrote:

I would like to propose the addition of two new combinators to Control.Monad:

ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m ()

[...]

f = do dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path

While I'm neutral on this proposal, I'd like to remind that LambdaCase may be useful to avoid temporary variables as well (and is even more useful for types other than Bool):

f = doesDirectoryExist path >>= \case True -> return () False -> do putStrLn $ "Creating directory " ++ path createDirectory path Cheers, hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

when' and unless' are good names in my opinion. In Haskell libs ' is often used to define a similar function to another one. For if' we could use the third convention. Its type is: if :: Bool -> a -> a -> a and by prefixing 'm' we can change it to be monadic: mif :: (Monad m) => m Bool -> m a -> m a -> m a that stands for monadic if. I don't like the idea of having different name notations for ifM and whenM/unlessM but that's true also for if-then-else and when/unless. I personally don't like the name 'mif' but I don't see many other solutions. Maybe the name 'if' isn't appropriate and it's better to change it into something else? On 04/20/2014 11:48 PM, Edward Kmett wrote:

if' is a commonly used name in user code for what is now called bool, but it also gets used all over the place for 'if' inside of EDSLs.

On Sun, Apr 20, 2014 at 5:45 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

I see. Another solution is to use if', when' and unless'.

On 04/20/2014 11:42 PM, Edward Kmett wrote:

...

My mistake. These rules are still in Control.Monad. I just scrolled right past them.

-Edward

On Sun, Apr 20, 2014 at 5:04 PM, Edward Kmett mailto:ekmett@gmail.com> wrote:

The principled objection to giving these combinators the "obvious" names in Control.Monad is that that module has historically held to a detailed convention that these proposed names unfortunately don't fit. =/

The functions in this library use the following naming conventions:

* A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example,

filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

* A postfix '_' changes the result type from (m a) to (m ()). Thus, for example:

sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m ()

* A prefix 'm' generalizes an existing function to a monadic form. Thus, for example:

sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a

That said, if we do adopt them, they probably should get the ifM, whenM, unlessM names.

I don't think the convention has been documented in Control.Monad itself for years.

-Edward

On Sun, Apr 20, 2014 at 4:26 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

Hi Herbert,

in general I like pattern matching but not when boolean values are involved. Your code is nice but, in my opinion, still far from the elegance of

f = unlessM (doesDirectoryExist path) $ do

putStrLn $ "Creating directory " ++ path createDirectory path

In particular, note that I don't have to take care of the False case and the code doesn't have boilerplate.

While your solution is more general, I would like to point out that when and unless are so useful that they got their own functions in the library instead of relying on pattern matching. I consider ifM, whenM and unlessM as alternate versions of existing functions.

On 04/20/2014 09:59 PM, Herbert Valerio Riedel wrote:

Hi Mario,

On 2014-04-20 at 21:10:03 +0200, Mario Pastorelli wrote:

I would like to propose the addition of two new combinators to Control.Monad:

ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m ()

[...]

f = do dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path

While I'm neutral on this proposal, I'd like to remind that LambdaCase may be useful to avoid temporary variables as well (and is even more useful for types other than Bool):

f = doesDirectoryExist path >>= \case True -> return () False -> do putStrLn $ "Creating directory " ++ path createDirectory path Cheers, hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

mif appears to pass the naming convention rules. It looks strange, but we can chalk that up to lack of exposure. The principal use of ' in base is for adding strictness, and when' and unless' don't fit that pattern. Looking at it in code doesn't send a signal that most users would pick up that an extra monadic effect is going on. -Edward On Sun, Apr 20, 2014 at 6:22 PM, Mario Pastorelli < pastorelli.mario@gmail.com> wrote:

when' and unless' are good names in my opinion. In Haskell libs ' is often used to define a similar function to another one.

For if' we could use the third convention. Its type is:

if :: Bool -> a -> a -> a

and by prefixing 'm' we can change it to be monadic:

mif :: (Monad m) => m Bool -> m a -> m a -> m a

that stands for monadic if. I don't like the idea of having different name notations for ifM and whenM/unlessM but that's true also for if-then-else and when/unless. I personally don't like the name 'mif' but I don't see many other solutions. Maybe the name 'if' isn't appropriate and it's better to change it into something else?

On 04/20/2014 11:48 PM, Edward Kmett wrote:

if' is a commonly used name in user code for what is now called bool, but it also gets used all over the place for 'if' inside of EDSLs.

On Sun, Apr 20, 2014 at 5:45 PM, Mario Pastorelli < pastorelli.mario@gmail.com> wrote:

...

I see. Another solution is to use if', when' and unless'.

On 04/20/2014 11:42 PM, Edward Kmett wrote:

My mistake. These rules are still in Control.Monad. I just scrolled right past them.

-Edward

On Sun, Apr 20, 2014 at 5:04 PM, Edward Kmett wrote:

...

The principled objection to giving these combinators the "obvious" names in Control.Monad is that that module has historically held to a detailed convention that these proposed names unfortunately don't fit. =/

The functions in this library use the following naming conventions:

...

- A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example,

filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

- A postfix '_' changes the result type from (m a) to (m ()). Thus, for example:

sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m ()

- A prefix 'm' generalizes an existing function to a monadic form. Thus, for example:

sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a

That said, if we do adopt them, they probably should get the ifM, whenM, unlessM names.

I don't think the convention has been documented in Control.Monad itself for years.

-Edward

On Sun, Apr 20, 2014 at 4:26 PM, Mario Pastorelli < pastorelli.mario@gmail.com> wrote:

...

Hi Herbert,

in general I like pattern matching but not when boolean values are involved. Your code is nice but, in my opinion, still far from the elegance of

f = unlessM (doesDirectoryExist path) $ do

putStrLn $ "Creating directory " ++ path createDirectory path

In particular, note that I don't have to take care of the False case and the code doesn't have boilerplate.

While your solution is more general, I would like to point out that when and unless are so useful that they got their own functions in the library instead of relying on pattern matching. I consider ifM, whenM and unlessM as alternate versions of existing functions.

On 04/20/2014 09:59 PM, Herbert Valerio Riedel wrote:

...

Hi Mario,

On 2014-04-20 at 21:10:03 +0200, Mario Pastorelli wrote:

...

I would like to propose the addition of two new combinators to Control.Monad:

ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m ()

[...]

f = do

...

dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path

While I'm neutral on this proposal, I'd like to remind that LambdaCase may be useful to avoid temporary variables as well (and is even more useful for types other than Bool):

f = doesDirectoryExist path >>= \case True -> return () False -> do putStrLn $ "Creating directory " ++ path createDirectory path Cheers, hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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: ,---- | $ zgrep -l '^\(when\|if\|unless\)M ' -- *.tar.gz | Adaptive-0.23.tar.gz | Adaptive-Blaisorblade-0.23.tar.gz | Agda-2.3.2.2.tar.gz | alms-0.6.5.tar.gz | alpha-1.0.15.tar.gz | apelsin-1.2.3.tar.gz | aws-sdk-0.12.4.tar.gz | bamboo-2010.2.25.tar.gz | bff-mono-0.2.1.tar.gz | bool-extras-0.4.0.tar.gz | btree-concurrent-0.1.5.tar.gz | buildbox-2.1.4.1.tar.gz | caldims-0.1.0.tar.gz | cao-0.1.1.tar.gz | clafer-0.3.5.1.tar.gz | Coadjute-0.1.1.tar.gz | Commando-1.0.0.4.tar.gz | concurrent-extra-0.7.0.6.tar.gz | cond-0.4.0.2.tar.gz | control-bool-0.2.1.tar.gz | control-monad-loop-0.1.tar.gz | ctrie-0.1.0.1.tar.gz | custom-prelude-0.2.2.0.tar.gz | darcs-benchmark-0.1.9.tar.gz | data-spacepart-20090215.0.tar.gz | DPM-0.3.0.0.tar.gz | feldspar-language-0.6.0.3.tar.gz | fix-imports-1.0.3.tar.gz | fquery-0.2.1.5.tar.gz | git-annex-5.20140412.tar.gz | github-backup-1.20131203.tar.gz | git-repair-1.20140227.tar.gz | hjs-0.2.1.tar.gz | hsc3-graphs-0.14.1.tar.gz | hsConfigure-0.1.tar.gz | hxt-filter-8.4.2.tar.gz | IfElse-0.85.tar.gz | infinity-0.3.tar.gz | JYU-Utils-0.1.1.2.tar.gz | kure-2.14.6.tar.gz | language-sh-0.0.3.1.tar.gz | lhae-0.0.3.tar.gz | libcspm-1.0.0.tar.gz | liquid-fixpoint-0.1.0.0.tar.gz | LslPlus-0.4.3.tar.gz | manatee-core-0.1.1.tar.gz | MiniAgda-0.2014.1.9.tar.gz | omega-1.5.2.tar.gz | orchid-0.0.8.tar.gz | panda-2009.4.1.tar.gz | processing-1.2.0.1.tar.gz | propellor-0.5.0.tar.gz | regexpr-0.5.4.tar.gz | rosso-1.0.tar.gz | runghc-0.1.0.2.tar.gz | scion-0.1.0.2.tar.gz | scyther-proof-0.8.0.0.tar.gz | shellish-0.1.4.tar.gz | shelly-1.5.2.tar.gz | sindre-0.4.tar.gz | spacepart-0.1.0.0.tar.gz | Strafunski-StrategyLib-5.0.0.3.tar.gz | StrategyLib-4.0.0.0.tar.gz | tamarin-prover-utils-0.8.5.1.tar.gz | test-sandbox-0.0.1.7.tar.gz | usb-1.2.tar.gz | vhd-0.2.2.tar.gz | watcher-0.0.3.0.tar.gz | wxc-0.90.1.1.tar.gz | YampaSynth-0.1.2.tar.gz | yesod-bin-1.2.8.1.tar.gz | yi-0.8.1.tar.gz | yjtools-0.9.18.tar.gz | zip-conduit-0.2.2.1.tar.gz | zoom-0.1.0.1.tar.gz `---- ...whereas a grep on the `m`-prefixed versions turns up much less hits: ,---- | $ zgrep -l '^m\(when\|if\|unless\) ' -- *.tar.gz | bool-extras-0.4.0.tar.gz | ideas-1.1.tar.gz `---- Cheers, hvr

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

I still believe in the intelligence of the masses, in particular when it comes to the evolution of vocabulary. Hayoo gives me 14 hits on "ifM", and 0 on "mif". +1 to ifM/whenM/unlessM -1 to mif/mwhen/munless CustomPrelude. ifM :: m Bool -> m a -> m a -> m a custom-prelude Control.Conditional. ifM :: m bool -> m a -> m a -> m a cond Bamboo.Helper. ifM :: m Bool -> m b -> m b -> m b bamboo Control.Monad.Tools. ifM :: m Bool -> m a -> m a -> m a yjtools Agda.Utils.Monad. ifM :: m Bool -> m a -> m a -> m a Agda Sindre.Util. ifM :: m Bool -> m a -> m a -> m a sindre Language.KURE.Combinators.Monad. ifM :: m Bool -> m a -> m a -> m a kure Test.WebDriver.Commands.Wait. ifM :: m bool -> m a -> m a -> m a webdriver Language.Fixpoint.Misc. ifM :: m Bool -> m a -> m a -> m a liquid-fixpoint Scion.Utils. ifM :: m Bool -> m a -> m a -> m a scion Feldspar.Core.Frontend.ConditionM. ifM :: Data Bool -> M a -> M a -> M a feldspar-language Control.Monad.Rosso1. ifM :: m Bool -> m a -> m a -> m a rosso Control.Monad.Adaptive.MonadUtil. ifM :: m Bool -> m a -> m a -> m a Adaptive-Blaisorblade Control.Monad.Adaptive.MonadUtil. ifM :: m Bool -> m a -> m a -> m a Adaptive On 21.04.14 11:35 AM, Mario Pastorelli 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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

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

On Mon, Apr 21, 2014 at 5:35 AM, Mario Pastorelli < 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

The API is there to serve its users, not really to dictate to them. If the common convention is counter to the API structure, perhaps it is the API that should change. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Mon, Apr 21, 2014 at 8:55 AM, Brandon Allbery wrote:

On Mon, Apr 21, 2014 at 5:35 AM, Mario Pastorelli 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

The API is there to serve its users, not really to dictate to them. If the common convention is counter to the API structure, perhaps it is the API that should change.

Has anyone noticed yet that replicateM is already breaking the ostensibly established naming scheme, and should properly be named mreplicate? Also, sequenceA is clearly echoing the fooM convention but it breaks the pattern even worse. But perhaps we should in fact rename replicateM. Certainly "mreplicate" would fit in better with other monadic variants of list functions, like "mconcat"! Consistency is important, after all. Also, mfix should probably be fixM, for what that's worth. - C.

On Mon, Apr 21, 2014 at 11:33 AM, Mario Pastorelli wrote:

On 04/21/2014 04:22 PM, Casey McCann wrote:

...

Has anyone noticed yet that replicateM is already breaking the ostensibly established naming scheme, and should properly be named mreplicate?

Sadly, replicateM breaks the naming scheme in a different way than ifM. The first doesn't justify the existence of the latter.

But it does somewhat deflate the notion that the fooM convention is consistently used, especially since replicateM and replicateM_ are probably more frequently used than many of the properly-named functions.

...

But perhaps we should in fact rename replicateM. Certainly "mreplicate" would fit in better with other monadic variants of list functions, like "mconcat"! Consistency is important, after all.

Also, mfix should probably be fixM, for what that's worth.

Don't you think that for compatibility reason this can be very problematic? How many people already used replicateM (and replicateM_) in their code? How many times?

Ah, so you're arguing that API consistency is sometimes outweighed by other concerns? I suppose I can't disagree with that. ;] Naming things is a matter of human language, and as a rule of thumb if everyone consistently breaks a linguistic "rule" in exactly the same way, it was the wrong rule. Figuring out what the actual rule being followed is and making it explicit is far more useful than trying to force a rule that runs counter to intuition. These functions have been reinvented many, many times under the names ifM &c., and between that and the strong association between the m prefix and MonadPlus/Monoid (as demonstrated by the fact you apparently didn't notice I compared "mreplicate" to "mconcat" above) I would argue that mif &c. are actually more misleading in this case, for the clear and simple reason that they're not the names most people would expect. Unless we plan to be absolutely and completely consistent, including renaming replicateM and mfix, we should use the widely established names in this case. - C.

Mario Pastorelli writes:

Only the name 'mif' respects the rules with this type. The more generic version of 'ifM' is

ifM :: Monad m => m Bool -> a -> a -> a

and I don't think there is a name conversion for this kind of function in Control.Monad.

Well, if you could actually implement the above function, convention would likely dictate that it be called "unsafeIf". David

I can write precisely 2 implementations of that function. They probably don't have the semantics you want, however. ;) -Edward On Mon, Apr 21, 2014 at 12:56 PM, David Mazieres < dm-list-haskell-libraries@scs.stanford.edu> wrote:

Mario Pastorelli writes:

...

Only the name 'mif' respects the rules with this type. The more generic version of 'ifM' is

ifM :: Monad m => m Bool -> a -> a -> a

and I don't think there is a name conversion for this kind of function in Control.Monad.

Well, if you could actually implement the above function, convention would likely dictate that it be called "unsafeIf".

David _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I, for one, could get behind just taking ifM, whenM, unlessM for these operations, proper naming conventions aside. They've been independently reinvented in 60+ packages with these exact names. If we do this, over time we'll save another 60+ packages the trouble of doing the same thing. -Edward On Mon, Apr 21, 2014 at 11:38 AM, Mario Pastorelli < pastorelli.mario@gmail.com> wrote:

On 04/21/2014 02:55 PM, Brandon Allbery wrote:

On Mon, Apr 21, 2014 at 5:35 AM, Mario Pastorelli < 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

The API is there to serve its users, not really to dictate to them. If the common convention is counter to the API structure, perhaps it is the API that should change.

I agree with you but I'm not the developer of this API. Considering how important is Control.Monad for Haskell I think it's important to pick the right name for new functions.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Mon, Apr 21, 2014 at 11:53 AM, Alexander Berntsen wrote:

...

If we do this, over time we'll save another 60+ packages the trouble of doing the same thing. This looks pragmatic now, but I, for one, think that in the future we would be appreciative of our decision to stick to conventions instead of giving in to the slippery slope of myopic pragmatism.

Descriptivism vs. prescriptivism. Somehow, prescriptivism never seems to work out in the long run; people do what they do. If they're added as mif etc., I expect those 60+ later packages will break out as 2 using the official ones and 58+ using homegrown ifM etc. still because their authors didn't notice the "weird names" ones. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Am 21.04.2014 17:53, schrieb Alexander Berntsen:

On 21/04/14 17:47, Edward Kmett wrote:

...

I, for one, could get behind just taking ifM, whenM, unlessM for these operations, proper naming conventions aside.

They've been independently reinvented in 60+ packages with these exact names.

If we do this, over time we'll save another 60+ packages the trouble of doing the same thing.

This looks pragmatic now, but I, for one, think that in the future we would be appreciative of our decision to stick to conventions instead of giving in to the slippery slope of myopic pragmatism.

I started to add monadic functions without M suffix or prefix to Control.Monad.HT module in my utility-ht package. This way I can write Monad.lift2, which is both readable and canonical. I don't see a reason why sometimes a prefix 'm' means Monoid and sometimes Monad. utility-ht is also very basic such that it can run on old GHC's and thus my packages do not need to depend in GHC-7.10 only because I like to use ifM.

On Mon, Apr 21, 2014 at 11:19 AM, Bardur Arantsson wrote:

On 2014-04-21 17:47, Edward Kmett wrote:

...

I, for one, could get behind just taking ifM, whenM, unlessM for these operations, proper naming conventions aside.

They've been independently reinvented in 60+ packages with these exact names.

If we do this, over time we'll save another 60+ packages the trouble of doing the same thing.

+1 (for the proposal, based on exactly the above summary)

+1 from me too, because I have the same functions with these names in my non-cabal packages. There might be a lot of non-cabal whenM etc. out there.

I'm +1 on whenM and unlessM - those I have wanted and think are very worthwhile. Regardless of the naming convention stuff (which I have never even been aware of in my day-to-day coding with Haskell), I think these are the right names, and they also match the naming with monad-loops (`whileM`, etc). I'd be -1 on mwhen, munless, etc. I'm +/-0 on ifM, but that doesn't seem to be in the original proposal anyway. I can see the value in it, but I've never really needed it. I would probably use f >>= bool x y in practice. - ocharles On Mon, Apr 21, 2014 at 7:34 PM, Brandon Allbery wrote:

On Mon, Apr 21, 2014 at 2:26 PM, Evan Laforge wrote:

...

On Mon, Apr 21, 2014 at 11:19 AM, Bardur Arantsson wrote:

...

On 2014-04-21 17:47, Edward Kmett wrote:

...

I, for one, could get behind just taking ifM, whenM, unlessM for these operations, proper naming conventions aside.

They've been independently reinvented in 60+ packages with these exact names.

If we do this, over time we'll save another 60+ packages the trouble of doing the same thing.

+1 (for the proposal, based on exactly the above summary)

+1 from me too, because I have the same functions with these names in my non-cabal packages.

There might be a lot of non-cabal whenM etc. out there.

And you're still missing a few with more specific type signatures, e.g. xmonad's whenX.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Mon, Apr 21, 2014 at 2:55 PM, Greg Weber wrote:

agreed. additionally, while when/unless/whenM/unlessM gets rid of a `return ()` branch, ifM does not. In situations where I have branching code containing more than just properly curried functions I will prefer an intermediate variable if I get to use the language built-in if/then/else that gets syntax highlighted and avoids parentheses. `$ do` avoids parentheses with when/unless/whenM/unlessM, but with a second branch the parentheses return for both.

Looking at my own uses of 'ifM', I use it either when the branches are short: ifM ((<=) <$> Pitches.pitch_nn prev_pitch <*> Pitches.pitch_nn this_pitch) (return (Pitch.Diatonic (-1))) (return (Pitch.Diatonic 1)) ifM (Maybe.isJust <$> get) cmd_advance (cmd_set play_selected_tracks) ifM (not . wanted <$> State.get_track_title track_id) (return Nothing) (f block_id track_id events) Or when the first branch is a short exception: ifM (Directory.doesFileExist fn) (return (Just fn)) $ ifM (Directory.doesFileExist (fn ++ "c")) (return (Just (fn ++ "c"))) (return Nothing) stretch_to_1 <- ifM Internal.is_root_block (return id) $ do ) $ \omit _args deriver -> ifM (Util.chance omit) (return mempty) $ do Granted that first one is not very good.

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

[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...

Now that I'm finally confident about the approach we take for base-compat[1] (thanks to João Cristóvão for code and discussion), I want to give it more love in the future. I can add them to Control.Monad.Compat as soon as they are committed upstream and re-export the upstream versions for base > 4.7.0. That way people who are willing to depend on base-compat can just import Control.Monad.Compat. Cheers, Simon [1] http://hackage.haskell.org/package/base-compat

While the rules claim that a prefix m stands for a generalization to monadic form, in practice it is a generalization to Monoid or MonadPlus. If we look at names starting with m, we find: mplus msum mfilter All of them operate on MonadPlus. None of these functions are straightforward generalizations where arguments or results are wrapped in a monad, rather they replace addition or concatenation by the MonadPlus monoidal operation. In the base library the other names prefixed with 'm' are mappend and mconcat from Data.Monoid. Again these are monoidal operations. So to me, 'm' means "monoidal", not "monadic generalization". -1 for mif, mwhen, munless. Twan On 2014-04-21 00:35, Edward Kmett wrote:

mif appears to pass the naming convention rules. It looks strange, but we can chalk that up to lack of exposure.

The principal use of ' in base is for adding strictness, and when' and unless' don't fit that pattern. Looking at it in code doesn't send a signal that most users would pick up that an extra monadic effect is going on.

-Edward

On Sun, Apr 20, 2014 at 6:22 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

when' and unless' are good names in my opinion. In Haskell libs ' is often used to define a similar function to another one.

For if' we could use the third convention. Its type is:

if :: Bool -> a -> a -> a

and by prefixing 'm' we can change it to be monadic:

mif :: (Monad m) => m Bool -> m a -> m a -> m a

that stands for monadic if. I don't like the idea of having different name notations for ifM and whenM/unlessM but that's true also for if-then-else and when/unless. I personally don't like the name 'mif' but I don't see many other solutions. Maybe the name 'if' isn't appropriate and it's better to change it into something else?

On 04/20/2014 11:48 PM, Edward Kmett wrote:

...

if' is a commonly used name in user code for what is now called bool, but it also gets used all over the place for 'if' inside of EDSLs.

On Sun, Apr 20, 2014 at 5:45 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

I see. Another solution is to use if', when' and unless'.

On 04/20/2014 11:42 PM, Edward Kmett wrote:

...

My mistake. These rules are still in Control.Monad. I just scrolled right past them.

-Edward

On Sun, Apr 20, 2014 at 5:04 PM, Edward Kmett mailto:ekmett@gmail.com> wrote:

The principled objection to giving these combinators the "obvious" names in Control.Monad is that that module has historically held to a detailed convention that these proposed names unfortunately don't fit. =/

The functions in this library use the following naming conventions:

* A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example,

filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

* A postfix '_' changes the result type from (m a) to (m ()). Thus, for example:

sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m ()

* A prefix 'm' generalizes an existing function to a monadic form. Thus, for example:

sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a

That said, if we do adopt them, they probably should get the ifM, whenM, unlessM names.

I don't think the convention has been documented in Control.Monad itself for years.

-Edward

On Sun, Apr 20, 2014 at 4:26 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

Hi Herbert,

in general I like pattern matching but not when boolean values are involved. Your code is nice but, in my opinion, still far from the elegance of

f = unlessM (doesDirectoryExist path) $ do

putStrLn $ "Creating directory " ++ path createDirectory path

In particular, note that I don't have to take care of the False case and the code doesn't have boilerplate.

While your solution is more general, I would like to point out that when and unless are so useful that they got their own functions in the library instead of relying on pattern matching. I consider ifM, whenM and unlessM as alternate versions of existing functions.

On 04/20/2014 09:59 PM, Herbert Valerio Riedel wrote:

Hi Mario,

On 2014-04-20 at 21:10:03 +0200, Mario Pastorelli wrote:

I would like to propose the addition of two new combinators to Control.Monad:

ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m ()

[...]

f = do dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path

While I'm neutral on this proposal, I'd like to remind that LambdaCase may be useful to avoid temporary variables as well (and is even more useful for types other than Bool):

f = doesDirectoryExist path >>= \case True -> return () False -> do putStrLn $ "Creating directory " ++ path createDirectory path Cheers, hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

All of the current fooM functions only need Applicative, and might over time be renamed to fooA. Similarly all current mfoo functions only need Alternative, and should be called afoo. So imho we’re free to choose a new naming scheme, and ifM, whenM and unlessM would be the first to truly live up to their postfix. Sjoerd On 21 Apr 2014, at 18:01, Dan Doel wrote:

Yes, I think the stated naming conventions are somewhat off on what is really in the module.

mfoo is generalizing foo to monads-with-extra-structure, in Control.Monad at least.

But fooM is generally about functions that 'sequence' multiple actions. For instance:

mapM f = sequence . map f

This also explains replicateM, as:

replicateM n = sequence . replicate n

And liftM through liftM5 are similar.

ifM, whenM, unlessM, etc. do not involve monads with extra structure, but they are about sequencing extra monadic stuff, which seems to be what the M suffix is actually about. So they seem like the better names.

-- Dan

On Mon, Apr 21, 2014 at 11:16 AM, Twan van Laarhoven wrote: While the rules claim that a prefix m stands for a generalization to monadic form, in practice it is a generalization to Monoid or MonadPlus. If we look at names starting with m, we find:

mplus msum mfilter

All of them operate on MonadPlus. None of these functions are straightforward generalizations where arguments or results are wrapped in a monad, rather they replace addition or concatenation by the MonadPlus monoidal operation.

In the base library the other names prefixed with 'm' are mappend and mconcat from Data.Monoid. Again these are monoidal operations. So to me, 'm' means "monoidal", not "monadic generalization".

-1 for mif, mwhen, munless.

Twan

On 2014-04-21 00:35, Edward Kmett wrote: mif appears to pass the naming convention rules. It looks strange, but we can chalk that up to lack of exposure.

The principal use of ' in base is for adding strictness, and when' and unless' don't fit that pattern. Looking at it in code doesn't send a signal that most users would pick up that an extra monadic effect is going on.

-Edward

On Sun, Apr 20, 2014 at 6:22 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

when' and unless' are good names in my opinion. In Haskell libs ' is often used to define a similar function to another one.

For if' we could use the third convention. Its type is:

if :: Bool -> a -> a -> a

and by prefixing 'm' we can change it to be monadic:

mif :: (Monad m) => m Bool -> m a -> m a -> m a

that stands for monadic if. I don't like the idea of having different name notations for ifM and whenM/unlessM but that's true also for if-then-else and when/unless. I personally don't like the name 'mif' but I don't see many other solutions. Maybe the name 'if' isn't appropriate and it's better to change it into something else?

On 04/20/2014 11:48 PM, Edward Kmett wrote: if' is a commonly used name in user code for what is now called bool, but it also gets used all over the place for 'if' inside of EDSLs.

On Sun, Apr 20, 2014 at 5:45 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com> wrote:

I see. Another solution is to use if', when' and unless'.

On 04/20/2014 11:42 PM, Edward Kmett wrote: My mistake. These rules are still in Control.Monad. I just scrolled right past them.

-Edward

On Sun, Apr 20, 2014 at 5:04 PM, Edward Kmett mailto:ekmett@gmail.com> wrote:

The principled objection to giving these combinators the "obvious" names in Control.Monad is that that module has historically held to a detailed convention that these proposed names unfortunately don't fit. =/

The functions in this library use the following naming conventions:

* A postfix 'M' always stands for a function in the Kleisli

category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example,

filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

* A postfix '_' changes the result type from (m a) to (m

()). Thus, for example:

sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m ()

* A prefix 'm' generalizes an existing function to a

monadic form. Thus, for example:

sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a

That said, if we do adopt them, they probably should get the ifM, whenM, unlessM names.

I don't think the convention has been documented in Control.Monad itself for years.

-Edward

On Sun, Apr 20, 2014 at 4:26 PM, Mario Pastorelli mailto:pastorelli.mario@gmail.com>

wrote:

Hi Herbert,

in general I like pattern matching but not when boolean values are involved. Your code is nice but, in my opinion, still far from the elegance of

f = unlessM (doesDirectoryExist path) $ do

putStrLn $ "Creating directory " ++ path createDirectory path

In particular, note that I don't have to take care of the False case and the code doesn't have boilerplate.

While your solution is more general, I would like to point out that when and unless are so useful that they got their own functions in the library instead of relying on pattern matching. I consider ifM, whenM and unlessM as alternate versions of existing functions.

On 04/20/2014 09:59 PM, Herbert Valerio Riedel wrote:

Hi Mario,

On 2014-04-20 at 21:10:03 +0200, Mario Pastorelli wrote:

I would like to propose the addition of two new combinators to Control.Monad:

ifM :: (Monad m) => m Bool -> m a -> m a -> m a whenM :: (Monad m) => m Bool -> m () -> m ()

[...]

f = do dirDoesntExist <- not <$> doesDirectoryExist path when dirDoesntExist $ do putStrLn $ "Creating directory " ++ path createDirectory path

While I'm neutral on this proposal, I'd like to remind that LambdaCase may be useful to avoid temporary variables as well (and is even more useful for types other than Bool):

f = doesDirectoryExist path >>= \case True -> return () False -> do putStrLn $ "Creating directory " ++ path createDirectory path Cheers, hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 2014-04-20 at 23:48:06 +0200, Edward Kmett wrote:

if' is a commonly used name in user code for what is now called bool, but it also gets used all over the place for 'if' inside of EDSLs.

Just a minor nit-pick, I had always assumed if' and bool had different argument ordering: bool :: a -> a -> Bool -> a bool f _ False = f bool _ t True = t (following the style of 'either'/'maybe') vs. if' :: Bool -> a -> a -> a if' True x _ = x if' False _ y = y (see http://www.haskell.org/haskellwiki/If-then-else)