Hi folks, I've just noticed that the evaluation order for reduce differs slight between Clojure 1.2.1 and 1.3.0.
If you have a lazy seq xs, (b c d ...) and an expression (reduce f a xs), then the initial evaluation order in 1.2.1 is what you'd expect: a, b, (f a b) But in 1.3.0, it's slightly different: a, b, c, (f a b) For reasons that I can't quite work out, reduce in 1.3.0 evaluates the first two items of a seq before evaluating the first accumulator (f a b), even when reduce is supplied with an initial value. Technically I shouldn't have code that relies on the evaluation order of lazy seqs, but I just thought I'd post this just in case anyone ran into a similar problem. I'm now rearranging my code so that any side-effects are pulled out of the Java iterator before I turn it into a seq. - James -- 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