It is making more sense now.
One other interesting thing that surprised me is: "There is not a
total ordering across types."
See discussion:
http://groups.google.com/group/clojure/browse_frm/thread/710848919c68981f/51ede18b2fd7ab96?lnk=gst&q=sorted-set#51ede18b2fd7ab96
Therefore things like (sort [nil true 42 "abc"]) will throw an
exception. This is understandable since there can be many types in
Clojure and we cannot really easily define their ordering.
Many thanks for explanation, Frantisek
On Feb 15, 3:22 pm, Rich Hickey <richhic...@gmail.com> wrote:
> On Feb 14, 11:10 pm, Chouser <chou...@gmail.com> wrote:
>
> > On Sat, Feb 14, 2009 at 7:19 PM, Stephen C. Gilardi <squee...@mac.com>
> > wrote:
>
> > > "set" is a hash set. It will never contain two items with equal hashes.
>
> > I don't think that's quite right. I don't think it matters in this
> > case, but hash values aren't guaranteed unique. A hash-map can have
> > two keys with the same hash value as long as = returns false. Vectors
> > and lists with the same values evaluate as equal:
>
> > user=> (= '(1 2) [1 2])
> > true
>
> Right, and therein lies the key to understanding the set behavior. A
> set will contain at most one of any set of equal values. Equal objects
> should have equivalent, but not necessarily unique, hash codes.
>
> When you have polymorphic collections, as does Clojure, you need to
> decide the type bounds of the equality test. If two collections needed
> to be precisely the same type in order to be equal, the system would
> be quite rigid, with lots of explicit copying and coercion.
> Essentially, the polymorphism would be worthless. It ends up being
> most flexible and useful to place the type bound as high up as
> possible in the hierarchy, but not so high as to blur the core
> distinctions between collection families. Clojure divides the
> collections up into families for equality purposes - sequential, maps
> and sets.
>
> I can't overstate how important collection polymorphism is to the
> design of Clojure.
>
> One tradeoff is that sometimes you'd like explicit type to be part of
> collection equality, but it would still beg the question as to where
> to place the bounds, if other than exact match. For instance:
>
> (count #{(hash-set 1) (sorted-set 1)}) === ???
>
> they are both sets but not the same exact type.
>
> Note that things are no different in Java, which also has polymorphic
> collections:
>
> (java.util.HashSet. [(java.util.ArrayList. [1 2])
> (java.util.LinkedList. [1 2])])
> -> #<HashSet [[1, 2]]>
>
> (class (first *1))
> -> java.util.ArrayList
>
> Rich
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
