On Jan 3, 2009, at 5:50 PM, Chouser wrote:
But as noted originally, hashes are a bit more strict than Clojure =: (= v1 l1) ==> true (get (hash-map v1 :found) l1) ==> nil
I see this as a bug. For clojure data structures, = maps to .equals and Java defines rules for the relationship between .equals and .hashCode that appear to be violated by the current Clojure implementation.
The value of == is that it's much faster than =, and responds well to working with primitive numbers: (time (dotimes [_ 123456789] (= 1 1.0))) ==> 1350.525414 msecs (time (dotimes [_ 123456789] (== 1 1.0))) ==> 18.603425 msecs(time (dotimes [_ 123456789] (== (int 1) (float 1.0)))) ==> 10.348273 msecs
That's quite a large performance advantage, and "==" does fit in with others like ">=" in being numeric only, 2 characters long, and made up of non-alphabetic characters.
I really like the story on equality (as implemented by "=") that Clojure provides (value equality of immutable objects, with almost no emphasis on object identity) as compared to the variety of different kinds of equality in Common Lisp.
I think "==" entered Clojure's vocabulary at a time when "=" did not compare numbers in a type independent way. Now that it does, and now that we can use "=" in almost all cases, I wonder if it would be an improvement to rename "==" to "num=" to express more clearly its primary use as a high performance version of "=" for numbers only.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
