Fork me on GitHub

Working on incorporating Alex’s tests, I’m noticing the new functions in Clojure 1.11. I see that CLJS-3331 (add update-vals and update-keys) addressed 2 of the functions, but I can’t see any of the other functions mentioned. Should I go ahead and add a ticket for them? Happy to implement if no one else has done it


The functions are: parse-long, parse-double, parse-uuid, parse-boolean, NaN?, and infinite?

Alex Miller (Clojure team)02:01:30

please carefully match the semantics in the Clojure functions for valid string / invalid string / non-string

Alex Miller (Clojure team)02:01:27

The results in those partitions are parsed value / nil / exception respectively

👍 1

I’ve put up a new patch on • removed the autogenerated version number • Incorporated Clojure tests • Renamed a function that was renamed in Clojure between alpha3 and alpha4 (`` -> clojure.math/negate-exact)


Added to introduce the new functions I mentioned last night


Thank you!


looks like all test passing, will try to do a closer review soon


I still have an old AppVeyer setup running and a couple tests failed there:


Taking a peek at some odd self-hosted test failures...


Almost all of these seem to be based on the distinction between -0 and 0 being lost. One stood out for me on lines 76-78:

FAIL in (test-pow) ([object Object]:170:7)
expected: (= ##-Inf (m/pow 0 -3))
  actual: (not (= ##-Inf ##Inf))
That’s strange, because Math.pow(0, -3) is positive infinity (that’s the same in both Java and JavaScript). So I looked at the original code:
(is (= ##-Inf (m/pow -0.0 -3.0)))
So the code being executed appears to be different to the original source. This suggests to me that the code being sent to the self-hosted compiler has been read and converted back into a string, and that leads to the -0 values losing their sign. Is that a thing that happens Mike?


There are probably symbols not intended to be public, like MAX-FLOAT-VALUE (see (I suspect dir on the Clojure and ClojureScript versions of this namespace would produce the same list of public names in the end)


I’m wondering why I left them public. I made the other values private 😕


Ahh, so @quoll in JVM ClojureScript, the reader is implemented in Clojure and evidently it can read -0.0, but the self-hosted reader doesn't handle the numeric literal -0.0 in that way...


Ah… they’re to equate to Double/MAX_VALUE and Double/MIN_VALUE


These are important constants to have access to. I need them internally, and because anyone in Clojure land can refer to these values I made them available for ClojureScript too… but with different names


JVM ClojureScript:

cljs.user=> (/ -0.0)
Self-hosted ClojureScript (Planck):
cljs.user=> (/ -0.0)


Nope… I made a mistake. They’re already in JavaScript. I should reuse those values and not redefine them. I’ll fix that now


So, this is likely down to a difference in the reader implementations


Perhaps it could be deemed a bug in the ClojureScript implementation of the reader...


Given that JavaScript reads these numbers and represents them internally correctly, then it would seem so?


Turns out the problem is not with the self-hosted reader, but at the other end (emission). Fix in


Cool, putting it all together with Paula's 2nd patch passes:

bananadance 1

I’ve added what I hope is the final path to This includes the tests on self-hosted since that now passes