On Sun, Dec 5, 2010 at 8:26 PM, Robert McIntyre <r...@mit.edu> wrote: > If sets don't have a set ordering, then why should seq on a set always > return the same order for the same set? > > If seq doesn't always return the a seq with the same order, then (nth > set 5) might be different than a future call to (nth set 5), > because the underlying sequence returned by the set might change. > > If seq on a set always returns a seq with the same order, then that > may limit the future efficiency of sets.
I'm fairly sure seq on a set is deterministic rather than random, and since the set is immutable ... I'd say that (identical? s1 s2) can guarantee (identical? (nth s1 n) (nth s2 n)) for all n without unduly constraining set implementation. Whether (= s1 s2) can still guarantee that is a bit more complicated. Hashset order is determined by the order of the hash codes of the elements. If there's a hash collision I suppose order of the colliding elements might be determined by what got conjed in first, and then (= s1 s2) would fail to guarantee that. One way around it that's performance cheap but somewhat memory expensive is to include next links in set and map entries, making them double as lists. This would impair structure sharing, however. Another is to make hash buckets keep items in a deterministic order -- somehow. None of this makes nth poorly defined for the specific case of sorted sets and maps. Nor does it change the fact that if the above is a problem, then (= s1 s2) doesn't guarantee (= (seq s1) (seq s2)), which might itself be regarded as a problem and, if so, is one that *already exists*. -- 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
