On Thu, 2009-03-05 at 16:12 -0800, Jonathan Cast wrote:

On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote:

...

In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server

forkIO is used with fix as in:

reader <- forkIO $ fix $ \loop -> do

(nr', line) <- readChan chan' when (nr /= nr') $ hPutStrLn hdl line

loop

Do you have to use fix? Or is there a way to write this with a "let"?

You can certainly use let:

reader <- forkIO $ let loop = do (nr', line) <- readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop

But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style.

Both are poorish style. reader <- forkIO $ forever $ do (nr', line) <- readChan; when (nr /= nr') $ putStrLn hdl line

On Sat, 2009-03-07 at 23:12 +0100, Martijn van Steenbergen wrote:

Derek Elkins wrote:

...

Both are poorish style.

reader <- forkIO $ forever $ do (nr', line) <- readChan; when (nr /= nr') $ putStrLn hdl line

This is fine assuming you always want to re-enter the loop. If you want to loop conditionally (which is most often the case), forever isn't going to work, unless you use exceptions.

If you are doing something else, use something else. This makes it clear that you -aren't- going to break out (non-exceptionally), i.e. the control flow is more obvious in this code than in the other versions. By your logic 'map' would be bad because not everything is a map, of course, this is precisely why using map, when applicable, is good.

Quoth Jonathan Cast :

You can certainly use let:

reader <- forkIO $ let loop = do (nr', line) <- readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop

But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style.

Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. Thanks, Donn cave PS - granted that "forever" is a fine alternative to either, I suppose it doesn't affect the style comparison above.

Two questions: a) This chat server implementation doesn't actually close the connection as a real one would need to do. If you use "forever" is there a way to end the loop so as to end the connection? b) In Section 5 of this paper: http://www.cs.yale.edu/~hl293/download/leak.pdf Comparing the definition of eSF and e reveals that the primary difference is

in the fixed-point operators they use. e uses Haskell’s built-in fixed-point operator, which is equivalent to the standard:

fix f = f (fix f) eSF, on the other hand, is defined in terms of the loop combinator, which ties the loop tighter than the standard fixed-point operator. In particular, note in Figure 6 that loop computes the value-level fixed point as z, but re-uses itself in the continuation part. This is the key to avoiding the space leak.

My reading is that the fix operator, at least in some cases, causes space leak. Where as the arrow's loop, which uses "let" model, doesn't have this issue. Question: Do I need to worry about space leak if I am using the fix to instead of the "let"? Thanks Daryoush 2009/3/5 Luke Palmer

On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave wrote:

...

Quoth Jonathan Cast :

...

You can certainly use let:

reader <- forkIO $ let loop = do (nr', line) <- readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop

But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style.

Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best.

I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see

let foo = ...

Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with:

fix $ \foo -> ...

I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself.

I know that it's a simple matter of scanning to the corresponding "in", but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument.

Luke

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Mar 6, 2009 at 1:48 AM, Daryoush Mehrtash wrote:

Question: Do I need to worry about space leak if I am using the fix to instead of the "let"?

If you need to worry about a space leak with fix, you need to worry about it with let. The reason arrows can tie the loop tighter is more about the nature of recursion in streams; an arrow "sees" that prior values of a signal are not used, whereas value recursion is much less restricted. If, for example, the arrow were a kleisli arrow over the list monad, this would not be possible. With the definition fix f = let x = f x in x, you should not see any performance difference, other than the standard HOF penalty if there is not enough inlining... but that should not be asymptotic anyway. Luke

Thanks

Daryoush 2009/3/5 Luke Palmer

...

On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave wrote:

...

Quoth Jonathan Cast :

...

You can certainly use let:

reader <- forkIO $ let loop = do (nr', line) <- readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop

But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style.

Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best.

I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see

let foo = ...

Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with:

fix $ \foo -> ...

I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself.

I know that it's a simple matter of scanning to the corresponding "in", but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument.

Luke

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe