user=> (def x (int-array 3)) #'user/x user=> x [0, 0, 0] user=> (def y (seq x)) #'user/y user=> (first y) 0 user=> (aset x 1 3) 3 user=> x [0, 3, 0] user=> (second y) 3 user=> (aset x 0 2) 2 user=> x [2, 3, 0] user=> (first y) 2
Here, (first y) returned first 0, then 2 without y being rebound in between. This is a bit disturbing; some seqs can't be counted on to remain constant. I'd expected (first y) once produced as a 0 to be carved in stone, while (second y) would be 3 because it would be lazily produced from the array only after the corresponding array cell was changed. For this, the seq implementation would be something analogous to (defn lazy-array-seq ([arr] (lazy-array-seq arr 0)) ([arr from-idx] (lazy-array-seq arr 0 (count arr))) ([arr from-idx end-idx] (if-not (= from-idx end-idx) (lazy-seq (aget arr from-idx) (lazy-array-seq arr (inc from-idx) end-idx))))) but apparently it's actually just a very thin wrapper around the array, something like a "Java Iterator with copy-on-next semantics". Perhaps it should be changed to behave something more like the lazy-array-seq function above? Probably the seq wrappers for java.util collections exhibit the same ... I hesitate to call it a "bug", but I'm not sure it's the best choice of semantics. My feeling is that once realized seq values should never change, however the seq was produced. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---