By 'same' I've meant an identical :).
Two collections equivalent by their values may easily have a different
order of their items. This is because in unordered collections, their
internal order (as any other implementation detail) must not be taken into
account when comparing for value equivalence.
user=> (def s1 #{-3 2 1})
#'user/s1
user=> (def s2 (apply sorted-set s1))
#'user/s2
user=> s1
#{1 -3 2}
user=> s2
#{-3 1 2}
user=> (identical? s1 s2)
false
user=> (= s1 s2)
true
user=> (= (seq s1) (seq s2))
false
user=> (seq s1)
(1 -3 2)
user=> (seq s2)
(-3 1 2)
JW
On Sat, Feb 8, 2014 at 9:22 PM, Andy C <andy.coolw...@gmail.com> wrote:
> First, thanks everybody for explanations of design decision behind map and
> collections. I should in fact change subject to seq semantics ;-).
>
> For me the bottom line is that while I do not care about order so much I
> still can count on that seq function will produce consistent sequences. Or
> wait a sec:
>
>
>
>> This might be too detailed a point, but I wanted to mention that while
>> you will always get the same order for the same collection (same as
>> determined by identical?, or Java ==, i.e. it is the same object in
>> memory), you are *not* guaranteed to get the same order for collections of
>> the same type that are equal to each other as determined by Clojure = or
>> Java .equals. In particular, if two values have the same hash value, then
>> if they are used as a set in a Clojure PersistentHashSet or a key in a
>> PersistentHashKey, they are put into a linear list in a hash bucket for
>> that hash value, and their order in that list can be different in different
>> sets/maps, and the order that (seq ...) returns on those sets/maps will be
>> different.
>>
>> I am not certain, but this might violate referential transparency
>> (replacing a value that is equals for another value in an expression will
>> always give you an equal result).
>>
>
> This is not too detailed. In fact this is the ultimate question. It would
> mean that two logically identical sets can produce different LazySeq's
> depending how they came to existence ...
>
>
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
