4 ms·

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

acdha 7y ago
Yeah, the Chrome team basically recommended not to, favoring using something like Babel instead: https://developers.google.com/web/updates/2018/05/bigint#polyfilling_and_transpiling_bigints https://developers.google.com/web/updates/2018/05/bigint#pol...
- anoncake 7y ago
  > 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.
  - tzs 7y ago
    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.
  - acdha 7y ago
    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.
derefr 7y ago
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 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.)
- anoncake 7y ago
  > 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.
  - derefr 7y ago
    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.
tzs 7y ago
Can you actually do a polyfill for this? I'd have guessed that it was too low level for that.
shiado 7y ago
There are some good big integer libraries already around. https://www.npmjs.com/package/big-integer https://www.npmjs.com/package/big-integer
kccqzy 7y ago
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.
spankalee 7y ago
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 https://github.com/GoogleChromeLabs/jsbi [2]: https://github.com/GoogleChromeLabs/babel-plugin-transform-jsbi-to-bigint https://github.com/GoogleChromeLabs/babel-plugin-transform-j...

Yeah, the Chrome team basically recommended not to, favoring using something like Babel instead: https://developers.google.com/web/updates/2018/05/bigint#polyfilling_and_transpiling_bigints https://developers.google.com/web/updates/2018/05/bigint#pol...

anoncake 7y ago
> 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.
- tzs 7y ago
  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.
- acdha 7y ago
  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.

derefr 7y ago

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 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.)

anoncake 7y ago
> 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.
- derefr 7y ago
  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.

tzs 7y ago

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

shiado 7y ago

There are some good big integer libraries already around. https://www.npmjs.com/package/big-integer https://www.npmjs.com/package/big-integer

kccqzy 7y ago

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.

spankalee 7y ago

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 https://github.com/GoogleChromeLabs/jsbi [2]: https://github.com/GoogleChromeLabs/babel-plugin-transform-jsbi-to-bigint https://github.com/GoogleChromeLabs/babel-plugin-transform-j...