Fork me on GitHub

@sritchie09 hrm odd, is ** a new-ish operator?

Sam Ritchie15:03:27

@dnolen ES2016, which I feel like is older than BigInt getting accepted. Can dig more when I'm at a machine

Sam Ritchie16:03:52

So ** is ES2016, and BigInt itself seems to be official only as of ES2020:

souenzzo15:03:23 > Supported by firefox 52+ (released mar/2017) > Supported by chrome 52+ (released jul/2016) Can't find a good reference, but seems to be ECMAScript 2016 Seems that closure compiler support it But it is in ES7 namespace


@sritchie09 happy to do (i.e. accept) something about ** but it will require extra care based on all the above


it is not as simple as just adding something


well perhaps - but will need sufficient testing to know it will not go wrong

Sam Ritchie19:03:19

@dnolen I’d be happy to make a patch, or push this forward in any way that’s helpful. I don’t have a good mental model for what would break… I do know that ** still does not allow for mixed types, so as a binary operator there are some choices to make. Do we coerce, or let the error pass through? Because of that I’d love @quoll to weigh in on thoughts on how to support BigInt properly, beyond **.


This has been rattling around in my head for a few days. The only way that you can do powers in Java is via java.lang.Math/pow, and this carries forward into Clojure. Any other approach is an extension, which isn't the direction for the std lib. So this suggests to me that is has to happen in clojure.math/pow. The problem is that we don't have polymorphic functions, so to make it work for BigInt we would be looking at some sort of test (like (if (instance? …)) or a multimethod. These would work, but at a small cost for each invocation. Is that acceptable? It makes me uncomfortable.

Sam Ritchie12:03:12

makes me uncomfortable too vs the current default. On the other hand, this is how the numeric tower is implemented in the JVM version: and the non-coercive versions are implemented under uncheckedAdd etc