Re: What guarantees (if any) does Clojure make about laziness?
Hi, this highly depends on the sequence function at hand. Usually they are guaranteed to be as lazy as possible. But the are two aspects: a) sometimes you need to look ahead to actually perform the action (eg. take-while or drop-while) and b) sometimes there might be a bug in the implementation and it is not as lazy as it could be. You can't do anything about a). And b) is very unlikely but also happened in the past. A bigger problem might be ChunkedSequences. Assume you have your promises in a vector. Then a (map deref ...) will deref ahead of the actually requested elements and you have to deliver on up to 32 promises to unblock the realisation of the map sequence. So the flatten is probably more about the datastructures introducing such a ChunkedSeq than about the flatten itself. Kind regards Meikel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
To the best of my knowledge the only guarantee you get is the *existence* of an upper bound on the size of the eagerly fetched chunk, so a potentially infinite lazy sequence will not result in an endless loop/OOME. The whole mechanism is based on a best-effort policy. On Friday, March 15, 2013 2:08:58 AM UTC+1, Paul Butcher wrote: Clojure's sequences are lazy - but is there anything that guarantees *how* lazy they are? To give a concrete example - given an infinite lazy sequence of promises: (def promises (repeatedly promise)) If, in one thread I do: (doseq [p (map deref promises)] (println p)) And in another thread, I call deliver on various elements of promises, will promises always be printed as soon as they're available? Or can things block for longer than they theoretically might because a later (undelivered) promise in the sequence is being realized? I've been doing some experiments, and in practice the above works just fine - promises are printed as soon as they theoretically might be. If, however, I put a flatten in place of the map then I seem to have to deliver one more promise before the first is printed. What I'm interested in here aren't practicalities. I'm interested in what Clojure and its libraries guarantee (if anything) about laziness. Is there an upper bound on how much of a sequence will be realized? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
On 15 Mar 2013, at 07:04, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: this highly depends on the sequence function at hand. Usually they are guaranteed to be as lazy as possible. But the are two aspects: a) sometimes you need to look ahead to actually perform the action (eg. take-while or drop-while) and b) sometimes there might be a bug in the implementation and it is not as lazy as it could be. You can't do anything about a). And b) is very unlikely but also happened in the past. So the word I'm interested in in that sentence is guaranteed. I can see, from reading the source, what's guaranteed by a particular lazy structure and/or function. But that's just a statement about the current implementation, which might change in a future version of the language/library. Are these guarantees stated anywhere, or is my only recourse reading the source and/or experimenting with examples? -- paul.butcher-msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher MSN: p...@paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
On 15 Mar 2013, at 08:28, Marko Topolnik marko.topol...@gmail.com wrote: To the best of my knowledge the only guarantee you get is the existence of an upper bound on the size of the eagerly fetched chunk, so a potentially infinite lazy sequence will not result in an endless loop/OOME. The whole mechanism is based on a best-effort policy. That sounds very plausible to me. Is there an official statement to that end anywhere? -- paul.butcher-msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher MSN: p...@paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
The fact that lazy-seq actually was introduced to increase laziness pretty much shows the path. There is no official specification of Clojure you could rely on bureaucratically. Kind regards Meikel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
This is not about bureaucracy --- it's about API contract, and there is *no* * *contract to speak of for lazy sequences. Even the guarantee that it won't try to fully realize an infinite sequence is just word of mouth, and more of a common-sense guarantee than anything else. Basically, coding against lazy seqs only imposes a burden and gives no relief in return: you *must* preserve laziness whenever applicable, but you *may not* take advantage of it by assuming any guarantees. -Marko On Friday, March 15, 2013 10:01:13 AM UTC+1, Meikel Brandmeyer (kotarak) wrote: The fact that lazy-seq actually was introduced to increase laziness pretty much shows the path. There is no official specification of Clojure you could rely on bureaucratically. Kind regards Meikel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
On 15 Mar 2013, at 09:23, Marko Topolnik marko.topol...@gmail.com wrote: This is not about bureaucracy --- it's about API contract, Quite. you must preserve laziness whenever applicable, but you may not take advantage of it by assuming any guarantees. Erm - I certainly hope that this isn't true. Otherwise, I wouldn't be able to write: (take 10 (repeatedly 0)) Because, without *some* guarantees, it might never terminate and/or consume all memory. Of course, the only guarantee that this requires is the one that you mentioned in your earlier mail, that there will be *some* upper bound to how much of the sequence is realised. But it would be nice if there was an official statement to that end somewhere. And if there are other guarantees that can be relied upon, it would be nice to know what they were... -- paul.butcher-msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher MSN: p...@paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What guarantees (if any) does Clojure make about laziness?
you *must* preserve laziness whenever applicable, but you *may not* take advantage of it by assuming any guarantees. Erm - I certainly hope that this isn't true. Otherwise, I wouldn't be able to write: (take 10 (repeatedly 0)) Because, without *some* guarantees, it might never terminate and/or consume all memory. Exactly :) I have tried in vain to find any official statement on this. Throughout the API documentation you'll find guarantees such as preserves laziness, returns a lazy sequence, but nowhere do I find any commitment at all to the content of that term. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
What guarantees (if any) does Clojure make about laziness?
Clojure's sequences are lazy - but is there anything that guarantees *how* lazy they are? To give a concrete example - given an infinite lazy sequence of promises: (def promises (repeatedly promise)) If, in one thread I do: (doseq [p (map deref promises)] (println p)) And in another thread, I call deliver on various elements of promises, will promises always be printed as soon as they're available? Or can things block for longer than they theoretically might because a later (undelivered) promise in the sequence is being realized? I've been doing some experiments, and in practice the above works just fine - promises are printed as soon as they theoretically might be. If, however, I put a flatten in place of the map then I seem to have to deliver one more promise before the first is printed. What I'm interested in here aren't practicalities. I'm interested in what Clojure and its libraries guarantee (if anything) about laziness. Is there an upper bound on how much of a sequence will be realized? -- paul.butcher-msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher MSN: p...@paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
