Proposal: add ifM and whenM to Control.Monad

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Proposal: add ifM and whenM to Control.Monad

Mario Pastorelli
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 ()

The reason is that when you work in a `Monad m` the first argument of
`if` and `when` is often a `m Bool` and not a `Bool`. In those cases,
you have to write:

monadicOperationReturningBool >>= \b -> when b doAnotherMonadicOperation

or

monadicOperationReturningBool >>= flip when doAnotherMonadicOperation

to accomplish what you want to do. If you use the do-notation this is
less terrible but you still need to assign a name to the boolean value.
Take for example:

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

in this snippet, dirDoesntExist is completely useless and its only
purpose it to be used in the next expression. With the new combinators
you could write:

f = whenM (not <$> doesDirectoryExists path) $ do
         putStrLn $ "Creating directory " ++ path
         createDirectory path

Many libraries on hackage already include these functions (I often use
Control.Conditional). For a list see
http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=whenM&start=0.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andreas Abel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 for both, plus

unlessM :: (Monad m) => m Bool -> m () -> m ()
unlessM mc ma = ifM mc (return ()) ma

(See, for instance,
https://hackage.haskell.org/package/Agda-2.3.2.2/docs/Agda-Utils-Monad.html
.)

On 20.04.2014 21:10, 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 ()
>
> The reason is that when you work in a `Monad m` the first argument
> of `if` and `when` is often a `m Bool` and not a `Bool`. In those
> cases, you have to write:
>
> monadicOperationReturningBool >>= \b -> when b
> doAnotherMonadicOperation
>
> or
>
> monadicOperationReturningBool >>= flip when
> doAnotherMonadicOperation
>
> to accomplish what you want to do. If you use the do-notation this
> is less terrible but you still need to assign a name to the boolean
> value. Take for example:
>
> f = do dirDoesntExist <- not <$> doesDirectoryExist path when
> dirDoesntExist $ do putStrLn $ "Creating directory " ++ path
> createDirectory path
>
> in this snippet, dirDoesntExist is completely useless and its only
> purpose it to be used in the next expression. With the new
> combinators you could write:
>
> f = whenM (not <$> doesDirectoryExists path) $ do putStrLn $
> "Creating directory " ++ path createDirectory path
>
> Many libraries on hackage already include these functions (I often
> use Control.Conditional). For a list see
> http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=whenM&start=0.
> _______________________________________________ Libraries mailing
> list [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


- --
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNUIiQACgkQPMHaDxpUpLMkiQCgwwUfJ/orQ9GNB3SsStc1SB/4
F/kAn0AZ04HBeRjlNk7QkZcjHZ6Am+37
=EBzJ
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Mario Pastorelli
+1 for unlessM

On 04/20/2014 09:38 PM, Andreas Abel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 for both, plus
>
> unlessM :: (Monad m) => m Bool -> m () -> m ()
> unlessM mc ma = ifM mc (return ()) ma
>
> (See, for instance,
> https://hackage.haskell.org/package/Agda-2.3.2.2/docs/Agda-Utils-Monad.html
> .)
>
> On 20.04.2014 21:10, 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 ()
>>
>> The reason is that when you work in a `Monad m` the first argument
>> of `if` and `when` is often a `m Bool` and not a `Bool`. In those
>> cases, you have to write:
>>
>> monadicOperationReturningBool >>= \b -> when b
>> doAnotherMonadicOperation
>>
>> or
>>
>> monadicOperationReturningBool >>= flip when
>> doAnotherMonadicOperation
>>
>> to accomplish what you want to do. If you use the do-notation this
>> is less terrible but you still need to assign a name to the boolean
>> value. Take for example:
>>
>> f = do dirDoesntExist <- not <$> doesDirectoryExist path when
>> dirDoesntExist $ do putStrLn $ "Creating directory " ++ path
>> createDirectory path
>>
>> in this snippet, dirDoesntExist is completely useless and its only
>> purpose it to be used in the next expression. With the new
>> combinators you could write:
>>
>> f = whenM (not <$> doesDirectoryExists path) $ do putStrLn $
>> "Creating directory " ++ path createDirectory path
>>
>> Many libraries on hackage already include these functions (I often
>> use Control.Conditional). For a list see
>> http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=whenM&start=0.
>> _______________________________________________ Libraries mailing
>> list [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> - --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> [hidden email]
> http://www2.tcs.ifi.lmu.de/~abel/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlNUIiQACgkQPMHaDxpUpLMkiQCgwwUfJ/orQ9GNB3SsStc1SB/4
> F/kAn0AZ04HBeRjlNk7QkZcjHZ6Am+37
> =EBzJ
> -----END PGP SIGNATURE-----

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Mario Pastorelli
These come up every few months.

Historically, I've always been -1 on their inclusion as they are simple compositions of more fundamental operations.

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

+1 from me.

-Edward


On Sun, Apr 20, 2014 at 3:10 PM, Mario Pastorelli <[hidden email]> 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 ()

The reason is that when you work in a `Monad m` the first argument of `if` and `when` is often a `m Bool` and not a `Bool`. In those cases, you have to write:

monadicOperationReturningBool >>= \b -> when b doAnotherMonadicOperation

or

monadicOperationReturningBool >>= flip when doAnotherMonadicOperation

to accomplish what you want to do. If you use the do-notation this is less terrible but you still need to assign a name to the boolean value. Take for example:

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

in this snippet, dirDoesntExist is completely useless and its only purpose it to be used in the next expression. With the new combinators you could write:

f = whenM (not <$> doesDirectoryExists path) $ do
        putStrLn $ "Creating directory " ++ path
        createDirectory path

Many libraries on hackage already include these functions (I often use Control.Conditional). For a list see http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=whenM&start=0.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by Mario Pastorelli
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Mario Pastorelli
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Wiegley-2
In reply to this post by Edward Kmett-2
>>>>> Edward Kmett <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> wrote:
>>>>> Edward Kmett <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Mario Pastorelli
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries





_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Mario Pastorelli
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries






_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
i'm slightly meh about that Idea because i'll keep on misreading it as "milf" rather than "mif"


On Sun, Apr 20, 2014 at 6:22 PM, Mario Pastorelli <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries






_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Mario Pastorelli
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries







_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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

Good!


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.

You are right about the fact that they don't recall the fact that they are monadic versions. The problem is that without prepending or appending the letter 'm', how can we make clear to the user that it is the monadic version of another function? The only solution is to find other names but that's also bad in my opinion.

What about adding a new rule? Appending 'm' lowercase instead of 'M' uppercase stands for an alternative version of a function with the first argument monadic. So
forM follows the first rule while whenm follows the new rule. Bonus: also if could be defined as ifm :: (Monad m) => m Bool -> a -> a -> a.


-Edward


On Sun, Apr 20, 2014 at 6:22 PM, Mario Pastorelli <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries








_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

wren romano
In reply to this post by Andreas Abel
+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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Greg Weber
I don't understand how the existing naming convention for promoting functions to monadic versions can apply to when/unless since they already operate on monads.

I would hesitate to use an 'm' prefix for monadic code is because the Monoid typeclass does that (mempty, mappend, mconcat).
I would support a change in the documented convention for the 'm' prefix to only being used for MonadPlus (in addition to Monoid).

+1 on  whenM and unlessM

I haven't found myself needing ifM, but I will look at my code and see if I was missing opportunities to make it nicer.


On Sun, Apr 20, 2014 at 4:22 PM, wren romano <[hidden email]> wrote:
+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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by Edward Kmett-2
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Simon Hengel
> 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.

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

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
1234