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
-~----------~----~----~----~------~----~------~--~---
