On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner <gardne...@gmail.com> wrote:
> 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?
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
The point was that you can't even rely on seeing all of the elements,
once each, in *some* order, unless the seq is a copy instead of a view
backed by the other data structure. And if it's a copy, it is
expensive to produce. And if it is expensive to produce, it can be
cached once produced. And if it can be cached once produced, nth can
give consistent results by consulting the cached seq.
Or, put another way: *either* there is a seq version of the collection
that has a stable, if effectively random, order (and nth can be made
to work) *or* simply walking (seq the-coll) will potentially produce
inconsistent behavior, such as walking (seq a-set) and seeing
duplicates, or walking almost anything and missing an element that was
in there.
The latter is clearly undesirable behavior when calling seq on a
nominally-immutable collection, so I do hope any collections whose
innards do rearrange have seq produce a seq-copy rather than a
seq-view. But if the collection either does not rearrange *or*
produces a seq-copy when seq'd, then nth can be made to work on it in
a consistent way.
And, of course, none of this affects the obviously ordered *sorted*
set or the obviously ordered *sorted* map, which was the case
originally under discussion.
--
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
