Fork me on GitHub

@andy.fingerhut starting at around 12:50 of (clojure data structures part 1 2012-12), there is something about comparison and hashing -- may be there's something there that clarifies things?


(on a side note, i got the date from: -- but the site shown during the talk appears to be the sourceforge site according the location field of the browser. if one visits, it appears that already in 2009, there was redirection in place from sf to so i'm skeptical of the date being 2012)


I am pretty sure all YouTube dates are the date the video was uploaded. That is all YouTube really knows.


Basically gives you a "created on or before this date", but not much more information than that.


makes sense


the presentation content does not mention atoms and those look like they were added in 2008-12, so that gives some clue


Clojurescript definitely uses unequal cached hash values to short-circuit comparison, eg nodes of a persistent vector. I find it hard to believe clj doesn’t do this too?


Do you have a pointer to any particular part of the ClojureScript source code for that handy? No worries if not.


Nevermind! CLJS doesn’t use hashes for comparison. It either changed or it never did and somehow I got the wrong impression


I thought I remembered -equiv on PHM PAM PV having a “same type” path that did node-by-node comparison of internal structures


but they are all generic item-by-item


Seems to me this strategy could really speed up e.g. react renders


I thought that it was believed that the identical? speedup for equal sub-maps or sub-vectors nested within a larger collection were thought to give most of the existing speedup possible there, but that is just plausible hearsay for me.


Without extra effort, they are not identical


I agree, that is part of the implementation of calculating and storing a cached value for the hash of a map. However, I do not believe it is ever called during a call of clojure.core/=. The 'eq' in the name 'hasheq' I believe means 'the Clojure-specific hash function, different than Java's hashCode, that returns a value (usually) consistent with clojure.core/=, rather than Java's equals method'


Thanks for finding that. That third link you show definitely looks like it is using comparison of hashCode values to speed up equality checks on maps. It was removed in 2011 with this commit, some time before the release of Clojure 1.4.0:


Note that it is using Java hashCode comparisons, not Clojure hasheq comparisons. I am pretty sure that would be incorrect in general for Clojure, since hashCode can be different even for two Clojure maps that return true for clojure.core/=, e.g. one has an Integer value, the other a BigInteger value, both with the same integer that is clojure.core/=, but not Java equals.


@bronsa the latest published tools.analyzer.jvm 0.7.2 depends on tools.reader 1.0.0-beta4. Deps have been bumped since then in the project but not released. Any reason not to release a new version with latest deps?


I'll cut a release


might want to check if deps should be bumped again prior, I didn't look that closely


yeah will do


released 0.7.3