moonlite:

On Mon, 2006-11-13 at 13:15 +1100, Donald Bruce Stewart wrote:

...

http://hackage.haskell.org/trac/ghc/ticket/997

[snip]

...

Along with the useful control combinator:

forever :: (Monad m) => m a -> m ()

[snip]

...

+-- | @'forever' act@ repeats the action infinitely. +forever :: (Monad m) => m a -> m () +forever a = a >> forever a

I would personally rather see repeatM and repeatM_ like the replicateM/replicateM_ pair already in Control.Monad.

I implement them like this: repeatM = sequence . repeat repeatM_ = sequence_ . repeat

Google CodeSearch tells me it's the way replicateM was implemented too: http://www.google.com/codesearch?hl=en&lr=&q=replicateM+file%3A%5C.hs% 24&btnG=Search

Btw, i hope it is ok to give my opinion on this. Im asking since im not a library developer or anything just a normal programmer.

On this topic, we can go back to: http://www.mail-archive.com/cvs-all@haskell.org/msg26511.html However, it was pointed out that repeatM is next to useless, and it is traditional to use 'forever' for repeatM_ (see for example "Tackling the Awkward Squad", and http://haskell.org/haskellwiki/Roll_your_own_IRC_bot That being said, repeatM_ isn't too bad, should people prefer it. -- Don

ndmitchell:

Hi

...

However, it was pointed out that repeatM is next to useless, and it is traditional to use 'forever' for repeatM_ (see for example "Tackling the Awkward Squad", and http://haskell.org/haskellwiki/Roll_your_own_IRC_bot

That being said, repeatM_ isn't too bad, should people prefer it.

If I had to guess what the monadic version of repeat was, I'd guess repeatM_ before forever. Forever is a very overloaded word, repeat in Haskell has exactly one concrete meaning agreed by everyone (since its in the Prelude).

Agreed. But 'forever' is a pretty special control structures, worthy of a special name. Consider the cuteness of: listen = forever $ do h <- get s <- io (hGetLine h) io (putStrLn s) if ping s then pong s else eval (clean s) versus: listen = repeatM_ $ do h <- get s <- io (hGetLine h) io (putStrLn s) if ping s then pong s else eval (clean s) Or, to quote the awkward squad, s2.4 "Control structures":

We can easily express an infinite loop as a combinator:

forever :: IO () -> IO () forever a = a >> forever a

I'm we're going to use this forever more, then a name more meaningful than repeatM_ might be appropriate (personally, I have to check every time whether it is replicate or repeat that is :: Int -> a -> [a]). -- Don

john:

On Mon, Nov 13, 2006 at 02:27:12PM +1100, Donald Bruce Stewart wrote:

...

I'm we're going to use this forever more, then a name more meaningful than repeatM_ might be appropriate (personally, I have to check every time whether it is replicate or repeat that is :: Int -> a -> [a]).

now it will be three times easier to remember, as you only need to remember what one of repeat, repeatM, and repeatM_ do to easily determine what the other two do. standard naming conventions are very nice when they fit so well, as they do in this case.

Ok :) I'll resubmit 'repeatM_' as a separate patch. -- Don

Hello Donald, Monday, November 13, 2006, 1:25:19 PM, you wrote:

...

...

I'm we're going to use this forever more, then a name more meaningful than repeatM_ might be appropriate (personally, I have to check every time whether it is replicate or repeat that is :: Int -> a -> [a]).

I'll resubmit 'repeatM_' as a separate patch.

i have one idea: this dispute between folks that prefer repeatM_ name and whose preferring forever form may just reflect differences between FP-oriented and imperative programming style. may be the best solution will be to create new Control.Imperative module and put all this imperative-alike stuff here. so, John Meacham can just ignore existence of such module while we can continue to decorate our imperative programs with such beautiful shortcuts: foreach = flip mapM for = flip mapM_ on = flip when forever = sequence_ . repeat new = newIORef (=:) = writeIORef ...... i'm pretty sure that for novices learning Haskell studying these names will be much simpler than studying Monad concepts and so on -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Aaron, Friday, November 17, 2006, 9:03:30 PM, you wrote:

...

i'm pretty sure that for novices learning Haskell studying these names will be much simpler than studying Monad concepts and so on

Which will eventually handicap them.

the key word here is "eventually" ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 11/17/06, J. Garrett Morris wrote:

Agreed. I would suggest this is no more useful than

f . g = g f

But... that is patent nonsense! (f . g) x = f (g x) Everyone knows that!

I think that both repeatM and repeatM_ should be added for the following reasons. 1. sequence . repeat and sequence_ . repeat are the only specifications that will ever be meant by the names repeatM and repeatM_ (in Control.Monad), so there is no concern for conflict or confusing with these names. 2. the implemention are exteremely short, so there is negligable harm in including them in distributions. 3. repeatM seems plausibly useful in at least the reader monad, and probably others. That being said, I also think it is a fine idea to add the forever function. Haskell thrives on multiple ways of doing the same thing. Giving users reasonable set of options is a good thing. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

Hello Mattias, Monday, November 13, 2006, 5:51:23 AM, you wrote:

Btw, i hope it is ok to give my opinion on this. Im asking since im not a library developer or anything just a normal programmer.

.. and you think that this list is for crazies only? :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Mon, 13 Nov 2006, Malcolm Wallace wrote:

dons@cse.unsw.edu.au (Donald Bruce Stewart) wrote:

...

...

Add Kleisli composition to Control.Monad.

(>=>) :: (Monad m) => (a -> m b) -> (b -> m c) -> (a -> m c) (<=<) :: (Monad m) => (b -> m c) -> (a -> m b) -> (a -> m c)

Does anyone have an opinion about these guys? :)

No. :-) I've never used them, nor wanted to, so I have no opinion. I can see the nice compositional pattern they embody though.

Strange, the first time, I used them, was processing HTML data parsed by HaXML. :-)

On 11/13/06, Donald Bruce Stewart wrote:

...

(>=>) :: (Monad m) => (a -> m b) -> (b -> m c) -> (a -> m c) (<=<) :: (Monad m) => (b -> m c) -> (a -> m b) -> (a -> m c)

Does anyone have an opinion about these guys? :)

I want them. See my timeout patch for a case where I wanted one of these and didn't have it (the catch filter expression). -- Taral "You can't prove anything." -- Gödel's Incompetence Theorem

taralx:

On 11/13/06, Taral wrote:

...

On 11/13/06, Donald Bruce Stewart wrote:

...

...

(>=>) :: (Monad m) => (a -> m b) -> (b -> m c) -> (a -> m c) (<=<) :: (Monad m) => (b -> m c) -> (a -> m b) -> (a -> m c)

Does anyone have an opinion about these guys? :)

I want them. See my timeout patch for a case where I wanted one of these and didn't have it (the catch filter expression).

Actually, my tests indicate that (>>>) and (<<<) can be used for any Monad. So are we defining these again?

Do you mean that we should just import Control.Arrow and use that? Something like: import Control.Arrow main :: IO () main = (x >>> y) 7 x :: Integer -> IO () x = print y :: a -> IO () y = const (return ()) -- Don

On 11/14/06, Taral wrote:

On 11/13/06, Donald Bruce Stewart wrote:

...

Do you mean that we should just import Control.Arrow and use that?

Why not?

Well, it doesn't do the same thing, for starters... @type runState (((\x -> return (x+1)) >>> (\y -> return (y*2))) 3) () <lambdabot> forall b (m :: * -> *). (Monad m, Num (m b), Num b) => (m b, ()) Does that look like Kleisli composition to you? It doesn't look like Kleisli composition to me... I think you are getting confused by the Arrow (->) instance, probably...

Taral wrote:

Actually, my tests indicate that (>>>) and (<<<) can be used for any Monad. So are we defining these again?

Yes, the Kleisli type "Kleisli a b = a -> m b" is an Arrow. No, it's not the same, since "a -> m b" is not an Arrow on a and b (it's not of the form "arrow a b"). -- Ashley Yakeley

dons:

...

http://hackage.haskell.org/trac/ghc/ticket/997

Add Kleisli composition to Control.Monad.

Kleisli composition of monads is a foundational feature missing from the current Control.Monad library. A recent discussion revealed solid support for its inclusion.

This patch adds:

(>=>) :: (Monad m) => (a -> m b) -> (b -> m c) -> (a -> m c) (<=<) :: (Monad m) => (b -> m c) -> (a -> m b) -> (a -> m c)

Does anyone have an opinion about these guys? :)

Wee need the functions, no matter which names. That said, I still like (=>>=) and (=<<=) better, but I'm not strongly opposed to the proposed names --- it's just that they sort of look like they might be more closely related with Ord than with Monad. Wolfram

On Mon, 13 Nov 2006, Ashley Yakeley wrote:

Donald Bruce Stewart wrote:

...

forever :: (Monad m) => m a -> m ()

This should be:

forever :: (Monad m) => m a -> m b

forever even has a different type than repeatM_. More reason to have both. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

...

forever even has a different type than repeatM_. More reason to have both.

Is anyone else feeling uncomfortably crowded by the current namespace exported by the haskell libraries?

I think a good naming criteria is "could anyone have a function defined with this name which _didn't_ do exactly what this one does". For example, repeatM_ - can anyone think of an alternative definition which didn't do the obvious thing? However forever could have loads of interpretations. Thanks Neil