Hacker News Reader

Comment by philbarr | Hacker News Reader

I feel sorry for whoever has to write the polyfill for this...

Bignums themselves are actually pretty easy to implement as a plain library, provided your language has a uint8-array type (not just a String type, which might require the content be utf-8 valid, or might only have facilities to operate on codepoints, or might cut the data off at the first NUL.)

JS already has a Uint8Array, so bignum libraries are easy. (Let me tell you though, there were JS bignum libraries before Uint8Array, and they were, ahem, “interesting.” I think a popular one built a byte-array abstraction on top of hex-encoded strings, and then built bignums on that.)

Actually supporting the literal syntax or the operators via a plain library is impossible; but you can just do it the other way around: encourage developers to use a bignum library (for now), and have said library just “bake down” to native BigInts when they’re available.

Since everybody until now who was using bignums in JS was using them through a library, this won’t be a hard change to make.

(And it’s already been done! https://www.npmjs.com/package/big-integer now bakes down to native BigInts when it can.)

As for the brazen developers who start writing code to directly use the native BigInt... I suppose they’ll have to have two versions of their compiled code units in their minified blob, with a loader shim that evals out the version of the class/module that does/doesn’t use bigints. Maybe we’ll see an JS-pipeline pass to generate this. (I’m not a JS dev, so I’m not sure if there’s already support for this kind of thing.)

> Actually supporting the literal syntax or the operators via a plain library is impossible; but you can just do it the other way around: encourage developers to use a bignum library (for now), and have said library just “bake down” to native BigInts when they’re available.

Can't you rewrite the syntax into something usable at runtime? Not that it were a good idea.

This ...might be possible, but the performance would indeed suck; you’d need to essentially ship half a compiler toolchain in your polyfill, and ensure that it gets run separately, non-async, so that the browser finishes installing it before attempting to interpret any more <script> tags. (And, presumably, all of your app’s source would be in the next script tag, so that your app can take advantage of native bigints; so your app wouldn’t load at all until the toolchain had finished bootstrapping.)

I’m guessing this has been done, to let the browser run—without backend compilation—<script type=“foo”> where foo is CoffeeScript or TypeScript or ClojureScript or what-have-you; but this one would be especially bad, because the thing it’d be targeting would still be Javascript, and so you’d have to rewrite all Javascript sources you encounter, with most of them likely never using native bigints but suffering the double-parsing overhead anyway.

Oh, and you’d have to override the ES6 module loader with one that also rewrites what it loads. Ugly.

Babel (a popular transpiler) already has a plug-in for BigInts https://babeljs.io/docs/en/babel-plugin-syntax-bigint

> Bignums themselves are actually pretty easy to implement as a plain library, provided your language has a uint8-array type (not just a String type, which might require the content be utf-8 valid, or might only have facilities to operate on codepoints, or might cut the data off at the first NUL.)

Or if your String type doesn't do any of those. Javascript strings will happily hold an arbitrary series of 16 bit numbers.

Even when something requires valid code points, you can still easily store arbitrary 8 bit values. Or 15/16/17/20 depending on how fussy you are. Unless you want it to be hacky, it shouldn't be notably worse than an array.

A more popular approach of building a bigint library is to store a number of a series of limbs, where each limb is an unsigned 32-bit or 31-bit quantity. Since IEEE754 double allows exact integer arithmetic up to 2^53, that's fine.

Yeah, the Chrome team basically recommended not to, favoring using something like Babel instead:

https://developers.google.com/web/updates/2018/05/bigint#pol...

> and they are also making it infeasible (in most cases) to transpile BigInt code to fallback code using Babel or similar tools.

That doesn't sound like a recommendation.

Yeah. The recommendation is to write your code now making explicit calls to a specific bigint library. Later, when the JavaScript in the browsers you need to target has built in bigint support, Babel can replace your library calls with code that uses the built in bigints.

For this to work, you need a library whose bigint behavior either exactly matches the built in implementation, or whose deviations are known and can reasonably be account for when translating to built in bigints.

The library they recommend is a JavaScript translation of their implementation of built in bigints, so should match numerically what the built in implementation does.

There may be other libraries that would be suitable, but it would be nice if everyone agreed on just one for this so that when the time comes to use Babel or similar to replace the library calls with use of the built ins, it only has to deal with one library.

Note the comma: I was specifically referring to the advice against attempting to polyfill it. The Babel reference was attempting to convey the idea that instead you need something on the same order of complexity as a compiler to do this properly, but the details about JSBI are why I linked to their writeup rather than trying to summarize it.

There are some good big integer libraries already around.

https://www.npmjs.com/package/big-integer

JSBI[1] is a polyfill for the BigInt semantics, without the syntax. Then there's a Babel transform[2] to compile to the native syntax if all your targets support it.

[1]: https://github.com/GoogleChromeLabs/jsbi

[2]: https://github.com/GoogleChromeLabs/babel-plugin-transform-j...

Have you tried implementing a simple bigint library? Except for division everything is easy. I can even write it in assembler, and for example addition is just an add instruction followed by some adc instructions. Subtraction likewise. Assuming you want grade school multiplication (not Karatsuba or something fancy) it's also straightforward.

Can you actually do a polyfill for this? I'd have guessed that it was too low level for that.

Reply on news.ycombinator.com