@ghadi Sorry for the directed ping, but also asking others, but I have a half-remembering of some code you wrote that demonstrates that at least some JVMs return methods matching by some partial signature in a non-deterministic order. Do you have that or a pointer to it handy?

No worries @andy.fingerhut I'll try to dig it up when I get home but essentially I called Class::getMethods on a clj function class, filtered only arity-0 things, and printed. You have to do it in fresh JVMs though

I think chouse_r had the original repro (would be nice to file an issue for it)

@bronsa I was just working on https://dev.clojure.org/jira/browse/CLJ-2358 and saw your note there. On https://github.com/clojure/tools.reader/blob/master/src/main/clojure/clojure/tools/reader.clj#L1013-L1015 this works except you’ve violated the doc string which claims same args in same order as read. You’ve made (read+string reader opts) call (read opts reader). This is sane, no doubt, but does not agree with the docstring or where I’m heading with CLJ-2358.

@alexmiller subtle, let me know which direction you're going for CLJ-2358 and I'll follow

will drop a patch shortly

but it’s basically doing what the docstring says

which is super irritating

breaking change on read+string then?

the docstring says "like read, taking the same args", but the impl doesn't, I don't see any way to make the impl match the docstring without changing the impl?

I'll wait for your patch for the answers :)

yes, changing the impl

https://dev.clojure.org/jira/secure/attachment/18535/clj-2358.patch

I’m saying the docstring is the intent and the impl was broken (in Clojure itself as well)

:thumbsup:

i=0; while clojure -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-alpha8"}}}' -e '(require (quote clojure.pprint))' -e "(let [lass fc (class #())] (clojure.pprint/pprint (vec (filter #(zero? (.getParameterCount %)) (.getMethods fc)))))"; do echo '---';  i=$(( i + 1 )); done

If my "Rich/Stu/Alex sense" is anywhere near accurate (probably not), the fact that the JVM gives back a non-deterministic order here, leading to some people maybe wishing that Clojure sorted the return value in some deterministic way, is a highly suspect, risky, and needs-more-thinking-time enhancement, not a bug fix, yes?

In my book non-determinism is usually a bug