2009/3/6 Daryoush Mehrtash <dmehrt...@gmail.com>: > 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? Yes, throw an exception and catch it from outside the forever.
> 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"? the definition of fix in Data.Function[1] actually uses let: fix :: (a -> a) -> a fix f = let x = f x in x [1] http://darcs.haskell.org/packages/base/Data/Function.hs > Thanks > > Daryoush > 2009/3/5 Luke Palmer <lrpal...@gmail.com> >> >> On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave <d...@avvanta.com> wrote: >>> >>> Quoth Jonathan Cast <jonathancc...@fastmail.fm>: >>> >>> > 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 >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
