sorry to jump in this weird conversation, but it seems to me that you are on
parallel discussion without acknowleding it.
To me, the only thing which makes sense is that saying that seq promises no
deterministic ordering on sets and maps is not about calling seq on the same
java instance of a set or map twice.
It's just about acknowledging that, for example :
(not= (seq m) (rest (seq (assoc m :key :value)))) ;; silly example
or that two sets or maps appearing to be = , but not constructed via the
same assoc(iations) in the same order will not provide items in the same
order when seq is called on them:
user=> (def m1 {:k1 :v1 :k2 :v2})
#'user/m1
user=> (def m2 {:k2 :v2 :k1 :v1})
#'user/m2
user=> (into () (seq m1))
([:k2 :v2] [:k1 :v1])
user=> (into () (seq m2))
([:k1 :v1] [:k2 :v2])
user=> (= m1 m2)
true
user=>
2010/12/7 Ken Wesson <kwess...@gmail.com>
> 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<clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
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
