cljs-dev

2023-09-12T19:28:03.515799Z

This message contains interactive elements.

borkdude 2023-09-12T20:24:13.037629Z

I've also gotten a related question for squint and cherry if 123N should be parsed as a BigInt

borkdude 2023-09-12T20:24:41.137509Z

but I said: well, this will likely result into incompatibilities

2023-09-12T20:25:35.726689Z

So we're happy with edn data not being able to be round tripped because of type mismatches?

borkdude 2023-09-12T20:26:49.714079Z

When I got the question it wasn't about EDN, but about code. You can get backward incompatibilities when people rely on (+ 10 10N) to work in both Clojure and CLJS

borkdude 2023-09-12T20:27:05.445199Z

when you change 10N to BigInt, (+ 10 10N) no longer will work

2023-09-12T20:27:28.346669Z

Ah, so it's a larger issue with CLJS just not having a proper numeric tower?

borkdude 2023-09-12T20:28:01.745539Z

I've never relied on this notation myself, so perhaps it's not an issue, but this something that could potentially break people's code as CLJS has converted 10N to a normal number

2023-09-12T20:46:22.530739Z

I'm curious how big that impact would actually be if CLJS' numeric functions were updated to deal with a proper numeric stack that included arbitrary precision integers and decimals.

borkdude 2023-09-12T20:47:09.765669Z

the numeric "functions" often just translate into raw "+" JavaScript calls

borkdude 2023-09-12T20:47:24.401099Z

only in cases where + is used as a higher order function, is that avoided

2023-09-12T20:48:22.042569Z

Right, but part of me thinks that's bad default behavior and should only be turned on for specific parts of code that opt into it. But maybe I'm alone there.

borkdude 2023-09-12T20:49:20.985129Z

it's a huge performance loss if you would go through a function for those cases, but some of that can be avoided using the inference, just like for truthiness (which does go through a function, since that behavior in CLJS differs from JS)