Your example is so short that I cannot replicate it:
user=> (def a (hash-map -1 :a))
#'user/a
user=> (def b (array-map -1 :a))
#'user/b
user=> (= a b)
true
user=> (= (key (first a)) (key (first b)) -1)
true
I said to myself, "Ok he's been throwing some ints in there":
user=> (def a (hash-map (int -1) :a))
#'user/a
user=> (def b (array-map -1 :a))
#'user/b
user=> (= a b)
true
user=> (= (key (first a)) (key (first b)) -1)
true
Still ok.
Now if you have been using Integer and Long objects as key, of course maps will
not match.
You are using Java objects as keys, not primitive types. You're not in
Clojure's playground
anymore, half of your map is in Java's own sandbox.
What's missing from your shortened example ?
On Sat, 22 Oct 2011 14:23:24 -0700 (PDT)
Chris Perkins <chrisperkin...@gmail.com> wrote:
> On Saturday, October 22, 2011 4:31:29 PM UTC-4, Luc wrote:
> >
> > Where's the contract breach here ?
> >
> Glad you asked. Consider the following clojure session (1.3),
> shortened for your reading pleasure:
>
> map-1 => {-1 :yo}
> map-2 => {-1 :yo}
> key-1 => -1
> key-2 => -1
>
> Just some simple maps and values, right?
>
> (= map-1 map-2) => true
> (= key-1 key-1 -1) => true
>
> Yup, they're the same. But:
>
> (map-1 key-1) => :yo
> (map-2 key-1) => :yo
> (map-1 key-2) => :yo
> (map-2 key-2) => nil
>
> Oops! Despite being "equal", the two maps behave differently. Why?
>
> (class map-1) => clojure.lang.PersistentArrayMap
> (class map-2) => clojure.lang.PersistentHashMap
> (class key-1) => java.lang.Integer
> (class key-2) => java.lang.Long
>
> Unless I am mistaken, the difference between an ArrayMap and a
> HashMap is supposed to be an implementation detail - an optimization.
> I'm sure that they shouldn't have different semantics. But when
> hashCodes and equality do not agree, this is the sort of thing that
> can happen.
>
> Note that I'm not claiming to have any deep insights into what's
> broken and what's not, either in Clojure or in Java. All I'm saying
> is that claiming anything along the lines of "Clojure is not Java, so
> we can do whatever we want - contracts do not apply" does not lead to
> sane map behavior. Those contracts were created for a reason.
>
> To be honest, I've sort-of lost the plot of how this is related to
> the boxing-ints-as-Longs issue, but that's probably due to both my
> lack of expertise in this area and to the generous glass of whiskey I
> had while watching Megamind with my kids this afternoon. But I
> digress. The point I think I was trying to back up is "if clojure
> changes equality semantics, it should change hashcodes to match".
> That sounds right to me.
>
> - Chris
>
>
--
Luc P.
================
The rabid Muppet
--
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
