cljs-dev

dnolen 2026-05-15T12:29:45.362619Z

@iarenaza thanks for bringing it up 🙂

2026-05-15T15:35:21.585139Z

What is standard behavior for ratio literals in CLJS? We're seeing different behavior from the https://cljs.io/ REPL and from running tests via npx shadow-cljs compile test (https://github.com/jank-lang/clojure-test-suite/blob/main/bb.edn for more context) CC @jeaye @droberts3

dnolen 2026-05-18T12:45:56.136789Z

Yes no ratios, getting ratios to work is a biggish project, since it means adding a tower CLJS, also how not to slow down the reliance of the data structures on 32bit integer ops

1
p-himik 2026-05-15T15:53:18.507079Z

What exactly is the difference in the behaviors? FWIW, the web REPL is made with self-hosted CLJS. I assume your tests use regular CLJS.

souenzzo 2026-05-15T19:02:24.860869Z

Ratios are not supported in .cljs and .cljc files/REPL's https://github.com/clojure/clojurescript/blob/v1.12/src/main/clojure/cljs/compiler.cljc#L307-L308

cljs.user=> 1/2
Unexpected error (ExceptionInfo) compiling at (REPL:1).
failed compiling constant: 1/2; clojure.lang.Ratio is not a valid ClojureScript constant.
this replumb self-hosted REPL is a "custom build", that (maybe unintentionally) end up supporting ratios.

👍🏻 1
p-himik 2026-05-15T19:11:37.554079Z

IIRC it's just a self-hosted version of CLJS and there's nothing special about it. CLJS, when self-hosted, uses a CLJS reader and not a CLJ one - so there can be no errors about clojure.lang.Ratio. Here's how it behaves in a vanilla self-hosted CLJS:

(cljs/eval-str st "1/2"
    nil
    {:eval node-eval
     :context :expr}
    (fn [res]
      (println res)))
{:ns cljs.user, :value 0.5}
nil
cljs.user=>

p-himik 2026-05-15T19:13:42.268419Z

The culprit is cljs.tools.reader.impl.commons/match-number - it matches against (def ratio-pattern #"([-+]?[0-9]+)/([0-9]+)") and emits a plain division via cljs.tools.reader.impl.commons/match-ratio.

👀 1
iarenaza 2026-05-15T06:28:54.348729Z

@dnolen Great! Thank you. I must have looked at the wrong commit version, because I saw that 1.12 was still depending on the vulnerable version of the dependency. Sorry for the noise!