This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-01
Channels
- # announcements (2)
- # architecture (8)
- # babashka (21)
- # beginners (75)
- # calva (3)
- # clj-kondo (6)
- # cljdoc (6)
- # cljs-dev (10)
- # clojars (4)
- # clojure (94)
- # clojure-europe (12)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-spec (6)
- # clojure-uk (4)
- # clojurescript (51)
- # community-development (13)
- # core-async (3)
- # css (1)
- # cursive (8)
- # datomic (7)
- # girouette (3)
- # graphql (3)
- # improve-getting-started (4)
- # integrant (2)
- # interop (5)
- # jobs (12)
- # kaocha (1)
- # lsp (24)
- # malli (4)
- # membrane (13)
- # nextjournal (9)
- # off-topic (6)
- # re-frame (9)
- # reitit (2)
- # remote-jobs (1)
- # reveal (4)
- # ring (4)
- # scittle (3)
- # shadow-cljs (4)
- # spacemacs (1)
- # testing (2)
- # vrac (1)
@sritchie09 hrm odd, is **
a new-ish operator?
@dnolen ES2016, which I feel like is older than BigInt getting accepted. Can dig more when I'm at a machine
So **
is ES2016, and BigInt
itself seems to be official only as of ES2020: https://www.javascripttutorial.net/es-next/javascript-bigint/
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Exponentiation
> 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
https://github.com/google/closure-compiler/blob/master/test/com/google/javascript/jscomp/Es7RewriteExponentialOperatorTest.java#L52
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
@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.
makes me uncomfortable too vs the current default. On the other hand, this is how the numeric tower is implemented in the JVM version: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Numbers.java
and the non-coercive versions are implemented under uncheckedAdd
etc