On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote: > 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.
Ah, I misunderstood what you wrote. Obviously (seq) should hand you each item in the collection exactly once, but that's at a weaker guarantee than that different calls to (seq) on the same collection should always hand them to you in the same order. > 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. I don't see how this follows. It seems like you're making some unstated assumptions about how (seq) gets items from the underlying collection. > 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. It's not just about (nth) giving consistent results. It's also about forcing the programmer to make his intentions explicit, per Rich's quote. -- 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
