Laziness enhances composability: an example

Hi, I'm wondering what a good example of why laziness enhances composability would be. I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell. Thanks, Cristiano

Hello, A wonderful, and practical example, is the techniques in this modular lazy search paper: http://web.cecs.pdx.edu/~apt/jfp01.ps They build simple solvers, like backtracking, backjumping, etc. and then compose them together like: bt . bj The techniques are very much based on laziness. - jeremy At Thu, 9 Jul 2009 14:55:09 +0200, Cristiano Paris wrote:
[1
] [1.1 ] Hi, I'm wondering what a good example of why laziness enhances composability would be. I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell.
Thanks,
Cristiano [1.2
] [2
] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 9 Jul 2009, at 14:55, Cristiano Paris wrote:
Hi,
I'm wondering what a good example of why laziness enhances composability would be.
I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell.
Pretty much anything that uses "tying the knot" is very difficult to implement in a non-lazy language without a lot of indirection. Bob

Thomas Davie wrote:
On 9 Jul 2009, at 14:55, Cristiano Paris wrote:
I'm wondering what a good example of why laziness enhances composability would be.
I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell.
Pretty much anything that uses "tying the knot" is very difficult to implement in a non-lazy language without a lot of indirection.
I disagree; mutation can work rather well instead. One application I work on has to parse input containing items with forward and backward references using keys into a graph of objects, a classic tying-the-knot problem. However, we are not using a lazy language, so have only one procedure to create or look up the object corresponding to an item, by key. Parsing references to an item will just store the returned address, but parsing the definition of an item will mutate the object to fill in the data. The effect is that all the references end up as pointers to the right objects, and the objects for undefined items end up keeping their default values (caught by later checks). Situations like that make either mutation or laziness very handy, and if one cannot imagine the "tying the knot" technique then mutation looks like the only good way. No wonder people don't "get" pure FP! ;-) -- src/

Hello Cristiano, Thursday, July 9, 2009, 4:55:09 PM, you wrote: the best known example is chessmate implementation in Wadler's "why functional programming matter" but i don't know much about Python iterators, so can't say what is difference. may be its' only simplicity since lazy lists is looks like and processed just as lists while generators in any other language is separate data structure
Hi, I'm wondering what a good example of why laziness enhances composability would be.
I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell.
Thanks,
Cristiano
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Thu, Jul 9, 2009 at 3:42 PM, Bulat Ziganshin
Hello Cristiano,
Thursday, July 9, 2009, 4:55:09 PM, you wrote:
the best known example is chessmate implementation in Wadler's "why functional programming matter"
but i don't know much about Python iterators, so can't say what is difference. may be its' only simplicity since lazy lists is looks like and processed just as lists while generators in any other language is separate data structure
Thanks. In fact, I was stuck trying to find an example which couldn't be written using Python's iterators. The only difference coming up to my mind was that Haskell's lists are a more natural way to express a program relying on laziness. That was the reason why added the clause "at least not elegantly" in my first post. Cristiano

On Thursday 09 July 2009, Cristiano Paris wrote:
Thanks. In fact, I was stuck trying to find an example which couldn't be written using Python's iterators. The only difference coming up to my mind was that Haskell's lists are a more natural way to express a program relying on laziness. That was the reason why added the clause "at least not elegantly" in my first post.
Hi, I recently tried writing some code to simulate a certain protocol in Python. I thought I'll go the "smart" way and rely on the Python yield construct to do a CPS transformation of my code. While this worked to a certain extent, composability was a problem, because any sub-procedure which used yield (and thus was an iterator) required being called in a rather inelegant way. Thanks! Marcin Kosiba

2009/7/9 Marcin Kosiba
On Thursday 09 July 2009, Cristiano Paris wrote:
Thanks. In fact, I was stuck trying to find an example which couldn't be written using Python's iterators. The only difference coming up to my mind was that Haskell's lists are a more natural way to express a program relying on laziness. That was the reason why added the clause "at least not elegantly" in my first post.
Hi, I recently tried writing some code to simulate a certain protocol in Python. I thought I'll go the "smart" way and rely on the Python yield construct to do a CPS transformation of my code. While this worked to a certain extent, composability was a problem, because any sub-procedure which used yield (and thus was an iterator) required being called in a rather inelegant way.
I think I'll investigate Python's Iterator composability. Cristiano

Bulat Ziganshin wrote:
Hello Cristiano,
Thursday, July 9, 2009, 4:55:09 PM, you wrote:
the best known example is chessmate implementation in Wadler's "why functional programming matter"
Aeh, ... "Wadler's" -> "Hughes'" -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de
participants (8)
-
Bulat Ziganshin
-
Cristiano Paris
-
Cristiano Paris
-
Janis Voigtlaender
-
Jeremy Shaw
-
Marcin Kosiba
-
Simon Richard Clarkstone
-
Thomas Davie