In the particular case given below, I'd assume that during the invocation of print-seq, the binding to "s" (the head of the sequence) would be retained, because my mental model for the execution environment of a function is that it is the environment in which they were declared, extended with the bindings for their parameters. So, anything inside that function execution should have a reference to that environment, and I would expect those bindings to exist until the function has completed. I seem to recall that in clojure's implementation, environments aren't reified as such, but I believe the behavior is the same.
If certain JDKs are smart enough to avoid this, I consider that an implementation detail of that JDK, and thus (as with most optimizations), it's not something you should depend upon for correctness. I can't dispute your point that subtle bugs can occur with seqs, but I think that in most cases, it isn't that bad. I'm hopeful that as we find these kinds of bugs in core clojure forms, that we can get them addressed. Most of the bugs of this sort that I've introduced in my own code have been relatively straightforward to diagnose and debug. On Nov 3, 2:47 pm, Brian Hurt <bhur...@gmail.com> wrote: > I agree. I don't like having to ditch seqs. And producers bring their own > downsides- for example, being imperative constructs, they open the door for > race conditions on multi-threaded code in a way that seqs don't. If > anything, producers have a more-limited range of applicability than seqs, or > even iterators, do. Also, polluting the meme-space with three constructs > which are very similiar, but subtly different, is also a problem I'm not > happy with. > > But here's an example of the sorts of problems we were hitting. OK, we all > know that doseq doesn't hold on to the head of the seq. But what if I > write: > (defn print-seq [ s ] > (doseq [ x s ] > (println x))) > Does this code hold on to the head of the seq (in the argument to the > function)? I'm honestly not sure- and strongly suspect that the answer > depends upon (among other things) which JVM you run the code on (and which > optimizations it will perform), and how long the code has been running (and > thus what optimizations have been performed on the code). > > And even if it doesn't, then I have no doubt that with a little > complication, I can develop code that does (or at least might) hold on the > head of the seq unnecessarily. Which means this is not only an issue for > the original writer of the code, but also the maintainer. > > It's not clear. If you know that millions of records are as large as you're > going to see, then seqs are the right tool- and if you load everything into > memory, oh well. If the number of records might creep into the billions or > trillions, then seqs (with their risk of wanting to keep everything in > memory) are a bad choice IMHO. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
