The crux of the issue:
user> (= (long 1) (int 1))
true
user> (.equals (long 1) (int 1))
false
user> (.equals (int 1) 1)
true
user> (.equals (long 1) 1)
false
So, as you can see, small integer literals are Integers by default in
Clojure. And, while Integers and Longs with the same value are
Clojure "=", they are not ".equal" to each other in Java-land.
Now, since Clojure's maps implement java.util.Map, they're supposed to
use java's .equals. (They must do so to use existing .hashCode methods
on Java objects). So, you get:
user> ({ (long 1) :found} (long 1))
:found
user> ({ (long 1) :found} 1)
nil
(If you want to lookup from your map with Long keys, you better make
sure the lookup keys are Longs too). Be careful to keep these
straight, a map can have distinct k-v pairs for different numeric key
types:
user> ({ (long 1) :found-a-long (int 1) :found-an-int} 1)
:found-an-int
Finally, the situation with sorted-map is a bit strange. For example,
see the third paragraph of:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/TreeMap.html
Now, Clojure's default comparator considers (long 1) and (int 1) to be
equal (see "(doc compare)"):
user> (compare (long 1) (int 1))
0
and so by default sorted-map does too. Note that the caveats
mentioned in the above webpage apply; technically, sorted-map with the
default comparator does not correctly implement the java.util.Map
interface, although in practice this may lead to more sensible-seeming
behavior.
Hopefully this helps, and I haven't misunderstood/misprepresented what
Clojure does here...
-Jason
--
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
