On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
> Perhaps. But under those circumstances seq itself has the same problem
> you're using to excuse not supporting nth, yet seq is supported. And
> so is (nth (seq x)) on these things; if the implementation changed its
> innards while you were walking the seq (even with map! Nevermind using
> nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
> would produce (1 3 4 5 2 6) and then someone makes another set from it
> with disj and the structure rearranges, so seq would now produce (1 5
> 6 2 4 3). Meanwhile, another thread has produced a seq and is
> traversing it at the time and gets (1 3 4 2 4 3). Oops.
Why is this a problem? Why would you rely on the order in which (seq) hands you
items from an unordered collection in the first place? If you care about order,
use an ordered collection. Besides that, it's really uncommon in my experience
to traverse the same collection twice while caring about the ordering.
The point of requiring a manual call to (seq) is to make it explicit that you
are viewing this thing as a seq, with all that implies. To quote Rich from the
previously-referenced thread:
"If in some situation it makes sense to treat a map as sequential (it might
make some sense with array maps or sorted maps), just use (seq m), which will
serve as an indicator of that special point of view."
Given the reasoning above, I'd argue that the fact that (first), (rest), and
(next) work on unordered collections is actually a bug.
--
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
