Clojurians Log v2
cljs-dev 2025-12-22
@dnolen I noticed that the newest CLJS has a new public function called str_ which still uses the unoptimized array.join stuff which was optimized in str. Do we still need str_, what for?
str_ is for code size
I don't understand. How does str_ produce better code size?
cljs.user=> (str (fn [] (str_ 1 2)))
"function (){\nreturn [cljs.core.str_((1)),cljs.core.str_((2))].join('');\n}"
cljs.user=> (str (fn [] (str 1 2)))
"function (){\nreturn (\"\"+(1)+(2));\n}"rest arg functions normally depend on IndexedSeq this is a non-trivial thing to pull in - it creates a kind of recursive reference later w/ printing, str_ breaks it
it also just makes DCE easier to reason about - w/o it, was pretty opaque
We could still optimize the str_ as macro bit perhaps so the internal calls just get compiled to +?
I wonder if this should be undefined? as well?
https://github.com/clojure/clojurescript/blob/c4295f303100bbf5afac449242d30bca1126f1a1/src/main/cljs/cljs/core.cljs#L3113
What if you call (str_ nil 1). I guess since it's only used internally it doesn't matter much since that's probably not the case right now, but can be a footgun later on perhaps
Anyway, my proposal would be to avoid the array + .join like we did for str and apply the same optimization to str_ too.
https://github.com/borkdude/clojurescript/commit/b0f9e0ac2e097674568a1fdd92912f6c567ecb6a
@dnolen found a bug I think.
cljs.user=> (refer-global :only '[String] :rename '{String Str})
nil
cljs.user=> String
#object[String]
cljs.user=> Str
#object[String]String should not be resolvable will :rename . I'll make an issue + patch if you agree.I agree, patch welcome
https://ask.clojure.org/index.php/14847/max-x-y-used-to-return-y-now-it-returns-x
@borkdude, I wrote the tests for min and max. They definitely try to test some negative cases. JVM throws exceptions if not a number; CLJS and others will sometimes accept them. Currently, the test suite captures that behavior. Over time, I expect those cases to be removed.
And Merry Christmas. 🙂
The "correct" answer to this is probably that you shouldn't rely on cljs.core/max for non-numbers
The context of this question is the jank clojure test suite which (over)tests all kinds of edge cases so it doesn't seem like a real "production" grade problem.
Yes max is only for numbers