John Wiegley | 25 Jul 21:16 2013

Proposal: Add Chris Done's "om" combinator to Control.Monad

The function is:

    om f m = (m >>=) . flip f

Allowing this typical usage:

    om when (return True) $
        print "Hello"

Thus, it allows one to do away with the monadic variants of pure functions,
such as "whenM", "unlessM", etc.:

    whenM   = om when
    unlessM = om unless

"om" gets even more handy when you want to apply a monadic function to a
monadic value in yet another monad:

    >>> om for_ (return (Just True)) print
    True

Rather than the typical (which I must have written hundreds of times by now):

    mx <- return (Just x)
    for_ mx $ \x -> {- use x... -}

A rider to this proposal is to also add "nom = flip om", but I can live
without that one.  "om", however, is handy enough that I've started locally
defining in all the modules where I find myself now reaching for it.

(Continue reading)

Ganesh Sittampalam | 25 Jul 23:21 2013
Picon

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

On 25/07/2013 20:16, John Wiegley wrote:
> The function is:
> 
>     om f m = (m >>=) . flip f
[...]
> A rider to this proposal is to also add "nom = flip om", but I can live
> without that one.  "om", however, is handy enough that I've started locally
> defining in all the modules where I find myself now reaching for it.

I have to admit my first reaction to this was that it isn't April 1st...

More seriously, "om" sounds useful but the name seems a bit obscure ("on
monad"?) Are there any examples of "nom" being useful?

Cheers,

Ganesh
Greg Fitzgerald | 26 Jul 19:57 2013
Picon

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

> Are there any examples of "nom" being useful?

I find 'nom' to be useful if defined as "const id":

-- Given 'om'
om f m = (m >>=) . flip f

-- And 'nom'
nom = const id

-- And the natural name for a monadic version of 'no'thing
noM = return ()

-- We construct a useful example of 'nom':
eatCookies :: IO ()
eatCookies = om nom noM noM

:-)

Happy Friday,
Greg

On Thu, Jul 25, 2013 at 2:21 PM, Ganesh Sittampalam <ganesh <at> earth.li> wrote:
> On 25/07/2013 20:16, John Wiegley wrote:
>> The function is:
>>
>>     om f m = (m >>=) . flip f
> [...]
>> A rider to this proposal is to also add "nom = flip om", but I can live
>> without that one.  "om", however, is handy enough that I've started locally
(Continue reading)

Henning Thielemann | 26 Jul 21:40 2013
Picon

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad


On Fri, 26 Jul 2013, Greg Fitzgerald wrote:

>> Are there any examples of "nom" being useful?
>
> I find 'nom' to be useful if defined as "const id":
>
>
> -- Given 'om'
> om f m = (m >>=) . flip f
>
> -- And 'nom'
> nom = const id
>
> -- And the natural name for a monadic version of 'no'thing
> noM = return ()
>
> -- We construct a useful example of 'nom':
> eatCookies :: IO ()
> eatCookies = om nom noM noM

So far I was not convinced by the proposal. But this one seems to be 
really useful and a real world application!
Andreas Abel | 27 Jul 00:41 2013
Picon

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

On 26.07.13 9:40 PM, Henning Thielemann wrote:
>> -- We construct a useful example of 'nom':
>> eatCookies :: IO ()
>> eatCookies = om nom noM noM
>
> So far I was not convinced by the proposal. But this one seems to be
> really useful and a real world application!

Fantastic!  That will make Haskell programming sweeter, while still a 
bit dry.  Maybe we should have some Java with it.

--

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

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
Stephen Tetley | 25 Jul 23:23 2013
Picon

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

Um (-1)...

This just looks like a synthetic combinator to me (cue the arbitrary name). Naturally it can make some code shorter (that's the point of combinators) but I have reservations that the code is significantly clearer, more appealing.


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 26 Jul 06:37 2013

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

>>>>> Stephen Tetley <stephen.tetley <at> gmail.com> writes:

> This just looks like a synthetic combinator to me (cue the arbitrary name).
> Naturally it can make some code shorter (that's the point of combinators) but I
> have reservations that the code is significantly clearer, more appealing.

It's just that I tend to write the following a LOT:

    x <- someMonadicFunction
    when x $ do
        ...

I generally avoid using whenM because it seems silly to bring in a package
dependency for something so trivial.  With "om", it's the same thing:

    om when someMonadicFunction $ do
        ...

I really didn't think it was that confusing or hard to read, but if people
dislike it on principle, I have no other arguments besides utility.  I find
myself reaching for it a lot, so thought others might too.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
Bryan O'Sullivan | 26 Jul 19:19 2013

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad


On Thu, Jul 25, 2013 at 9:37 PM, John Wiegley <johnw <at> fpcomplete.com> wrote:
It's just that I tend to write the following a LOT:

    x <- someMonadicFunction
    when x $ do

Sure, this is a common pattern. But the name is terrible, and it's not clear to me that the functionality is a useful generalization. Why not advocate for whenM instead?

whenM :: Monad m => m Bool -> m () -> m ()
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 26 Jul 23:27 2013

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

>>>>> Bryan O'Sullivan <bos <at> serpentine.com> writes:

> Sure, this is a common pattern. But the name is terrible, and it's not clear
> to me that the functionality is a useful generalization. Why not advocate
> for whenM instead?

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

The entire point of the proposal is that "om" subsumes such specialized
functions, saving you from having to use whenM, unlessM, etc.  You simply put
"om" (or whatever name you want to call it, the name wasn't the objective of
this proposal) in front of functions you already know and use, and suddenly
they become able to accept monadic arguments where they couldn't before.

Consider the "om forM_" example from before, which is actually quite handy and
clarifying, once you know how to read the combinator.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
Edward Kmett | 26 Jul 06:51 2013
Picon

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad

I'm -1 on this just because it is a rather awkward idiom to use, the name doesn't really make much sense and it is less fundamental than many of the things we've rejected on those grounds in the past. ;)


-Edward

On Thu, Jul 25, 2013 at 3:16 PM, John Wiegley <johnw <at> fpcomplete.com> wrote:
The function is:

    om f m = (m >>=) . flip f

Allowing this typical usage:

    om when (return True) $
        print "Hello"

Thus, it allows one to do away with the monadic variants of pure functions,
such as "whenM", "unlessM", etc.:

    whenM   = om when
    unlessM = om unless

"om" gets even more handy when you want to apply a monadic function to a
monadic value in yet another monad:

    >>> om for_ (return (Just True)) print
    True

Rather than the typical (which I must have written hundreds of times by now):

    mx <- return (Just x)
    for_ mx $ \x -> {- use x... -}


A rider to this proposal is to also add "nom = flip om", but I can live
without that one.  "om", however, is handy enough that I've started locally
defining in all the modules where I find myself now reaching for it.

--
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane