https://github.com/mentat-collective/emmy/blob/fe0e8bb755baf677cd615ba8e69be4f7f6f3ce40/src/emmy/value.cljc#L319

(For example)

Which isn't a great thing to do on a built-in type, especially if it's done in a library.

is there a good alternative?

in this case users can supply BigInt coefficients to a polynomial, and that data structure stores them in a map

I’m not sure what else to do here, given the errors that can appear once those maps get more than 8 entries

Do you use bigints as map keys or set entries? > is there a good alternative? Document what needs to be done if a user wants to use bigints. Optionally, provide an additional namespace that isn't used by anything but that can be required by a user to extend js/BigInt. This way, a user has full control over what's going on.

And it's the same for CLJ as well. One shouldn't extend something unconditionally. It might be fine to do in an app, it's absolutely not fine to do in a library unless it's meant to be the center of the universe for any project that uses it.

bigints are also automatically created by the polynomial gcd process… basically the arithmetic forces a promotion outside of the user’s control

@p-himik yes, agree. in this case it kind of is meant to be the center of the universe!

but yeah I do agree that some way to at least opt-out of this would be a good affordance

@p-himik I think supplying a hash code for js/BigInt is fine because there is already examples of native JS types being extended in cljs.core More importantly, BigInts as hash keys work in JVM Clojure, but not CLJS. So implementing IHash would help “converge” the behavior of Clojure and CLJS. Here is a quick demo in a Clojure REPL.

user> {0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 (bigint 9) "I'm accessible!"}
{0 0, 7 7, 1 1, 4 4, 6 6, 3 3, 2 2, 9N "I'm accessible!", 5 5, 8 8}
user> (get *1 (bigint 9))
"I'm accessible!"

I wish the numeric tower were at parity with the JVM version, especially as BigInt is a JS primitive

> in cljs.core Because that ns is the center of the CLJS universe. A third-party library is not. > More importantly, BigInts as hash keys work in JVM Clojure, but not CLJS That's what CLJS should solve though, or GCL, or a maintainer of an app (so the scope is limited only to that app), not a library. In fact, all interested parties can already create issues for https://github.com/google/closure-library and vote for https://ask.clojure.org/index.php/10938/can-js-bigint-be-used-as-a-map-key-in-clojurescript and even sign a CA and write a patch. ;) (Scratched out GCL because goog.getUid explicitly states that it accepts only objects whereas bigints are primitives).