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

Reply via email to