@andy.fingerhut starting at around 12:50 of https://youtube.com/watch?v=ketJlzX-254 (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: https://github.com/tallesl/Rich-Hickey-fanclub -- but the site shown during the talk appears to be the sourceforge site according the location field of the browser. if one visits http://archive.org, it appears that already in 2009, there was redirection in place from sf to http://clojure.org. so i'm skeptical of the date being 2012)
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?
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
sample lines with words that seem relevant: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentMap.java#L115_L123
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'
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.
Do you have a pointer to any particular part of the ClojureScript source code for that handy? No worries if not.
makes sense
the presentation content does not mention atoms and those look like they were added in 2008-12, so that gives some clue
i looked at something in 2008 and found these lines: https://github.com/clojure/clojure/blob/7de158ba6ee7cbf73e9f91fce4d038dd73b40789/src/clj/clojure/boot.clj#L447 https://github.com/clojure/clojure/blob/7de158ba6ee7cbf73e9f91fce4d038dd73b40789/src/jvm/clojure/lang/Util.java#L25 https://github.com/clojure/clojure/blob/7de158ba6ee7cbf73e9f91fce4d038dd73b40789/src/jvm/clojure/lang/APersistentMap.java#L60 https://github.com/clojure/clojure/blob/7de158ba6ee7cbf73e9f91fce4d038dd73b40789/src/jvm/clojure/lang/APersistentMap.java#L75_L90 how do those look?
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: https://github.com/clojure/clojure/commit/b5f5ba2e15dc2f20e14e05141f7de7c6a3d91179
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?
no
I'll cut a release
might want to check if deps should be bumped again prior, I didn't look that closely
and thx
yeah will do
released 0.7.3
thx!