[spec] Normative: Add i64<->BigInt conversion in JS API #707

littledan · 2018-02-17T20:14:08Z

See the JS-BigInt-integration proposal here:

https://github.com/WebAssembly/JS-BigInt-integration

jfbastien · 2018-02-17T20:36:35Z

This is a very significant change if applied towards the current working draft. Is your intent to keep this PR open until the public draft has shipped, and we can easily move non-editorial things into the spec?

littledan · 2018-02-17T21:14:26Z

@jfbastien I was imagining that this would stay as a PR for a while (at least until it meets the implementation requirements of WebAssembly proposals, for example). Is there something more that I should write up to frame this as a proper proposal?

I don't have a strong opinion about how this should relate to the W3C process, but for a comparison, ECMAScript continues development even during the several month IP opt out period, developing in the context of a working draft which follows the regular, official version cut. I don't see why this sort of model couldn't work for Wasm as well.

jfbastien · 2018-02-17T21:45:11Z

We've usually followed this process:
https://github.com/WebAssembly/meetings/blob/master/process/phases.md
(with edits in a PR that @flagxor has to review still)

So you only go to the spec repo after having a fork in a separate repo.

littledan · 2018-02-17T22:02:33Z

OK, this has a fork with the new spec in it (https://github.com/littledan/spec/tree/bigint) and a tracking issue in the design repo (WebAssembly/design#1172). The commit message here describes at a high level what this proposal is doing.

Should I put this commit message into a README.md in that repository, or is it sufficient in this location at the top of the thread? Either way, is the next step is to propose this feature for some sort of stage advancement at a WebAssembly Community Group meeting?

jfbastien · 2018-02-18T00:06:36Z

Tracking issues are the ones that I tag as such. The issue you link to is the "someone has an idea" step. Sorry, I know the process isn't great yet! Gotta improve what's written down.

Process would be that you put it on the agenda for the next CG meeting, and we'll poll to officially create a fork repo for it. Then we can transfer your repo to the organization, like TC39 does. Should pass easy, but I still want us to follow that process so we don't play favorites. It's also a really good way to keep the wider CG informed.

littledan · 2018-02-19T20:07:17Z

Oh, I see, the tracking issue and the fork have to be specifically approved. Makes sense. I didn't realize those words had special meanings here. I guess I'll put something on the CG agenda.

(In TC39, there are two processes for making changes: A formal staged proposal and a PR. We still don't play favorites, but sometimes smaller changes go through less paperwork.)

xtuc · 2018-02-20T07:05:40Z

Thanks @littledan! Sorry for my ignorance, how can you see the rendered version of the document?

xtuc

Does that means that a BigInt support is now required to be WebAssembly spec compliant?

Can we make it optional?

xtuc · 2018-02-20T07:17:56Z

test/js-api/jsapi.js

+  let module = new WebAssembly.Module(exportingModuleLongIdentityFn);
+  let instance = new WebAssembly.Instance(module);
+
+  let value = 2n ** 63n;


That assumes the host has the BigInt proposal support?

Yes, it does (this spec change requires the host to have BigInt support). When we split up this file, this test should probably be split off to let the others keep running on systems that don't support BigInt.

xtuc · 2018-02-20T07:20:17Z

document/js-api/index.bs

-1. If |w| is of the form [=𝖿𝟨𝟦.𝖼𝗈𝗇𝗌𝗍=] |f64|, return [=the Number value=] for |f64|.
+1. If |w| is of the form [=𝗂𝟨𝟦.𝖼𝗈𝗇𝗌𝗍=] |i64|,
+    1. Let |v| be [=signed_64=](|i64|).
+    1. Return a [=BigInt=] representing the mathematical value |v|.


Does "mathematical value" have a special meaning here? I don't think we need to mention math, It's just a value?

"Mathematical value" is a phrase used in the ECMAScript spec. It's discussed in this section but not really linkable. I'd be fine with deleting the word "mathematical" here if it's more confusing than helpful.

Ok, it's fine for me then. Let's maybe wait for another thought on this.

I think it's fine, but it should probably be "... of |v|". The link is https://tc39.es/ecma262/#mathematical-value, if you want to linkify it.

I don't think that's right: ES explicitly says that in the phrase "the mathematical value of x", x is a Number (i.e., a IEEE double) - which it definitely can't be at this point, because then we've lost precision.

Note that the numbers coming from wasm are already treated as "mathematical values" below, as they're passed to "the Number value for x", where x is expected to be a MV. We might want to formalize this a little more, but I'm not quite sure how to best do that.

Unless you feel strongly, I'd like to defer the linkifying until after this is merged.

rossberg · 2018-02-20T08:10:52Z

@xtuc, clearly we won't make this into a part of the Wasm standard before BigInt has become a part of the JS standard (it's getting there). At that point, though, there seems to be little point in making it optional.

littledan · 2018-02-20T11:25:03Z

@rossberg My hope is that this can be ready for implementations to ship at the same time as they are shipping BigInt.

I don't have a strong opinion about when it lands in the standard, but it really wouldn't be unusual at all for the Wasm standard to land while BigInt is at Stage 3 (given all the standards which make normative references to "Editor's Draft"s, this would be nothing--Stage 3 is something like "Candidate Recommendation").

jfbastien · 2018-02-20T16:48:00Z

I don't have a strong opinion about when it lands in the standard, but it really wouldn't be unusual at all for the Wasm standard to land while BigInt is at Stage 3 (given all the standards which make normative references to "Editor's Draft"s, this would be nothing--Stage 3 is something like "Candidate Recommendation").

What do you mean by "wouldn't be unusual"? It would be helpful to have points of reference on how we approach this. I'd like to have it as a topic for an upcoming CG meeting.

littledan · 2018-06-24T20:04:32Z

@jfbastien The HTML spec already references BigInt, for example.

xtuc · 2018-12-18T14:32:56Z

I think tthat this PR is obsolete, the specification and tests now lives under the proposal repo. Could we close this?

xtuc · 2019-03-04T15:43:33Z

@littledan could we close this PR in favor of the proposal repo?

littledan · 2019-03-05T09:03:51Z

We'll have to reopen the PR if the proposal ever reaches Stage 5; what is the problem with leaving it open?

See the JS-BigInt-integration proposal here: https://github.com/WebAssembly/JS-BigInt-integration

taralx · 2020-05-11T21:13:06Z

document/js-api/index.bs

-            1. If [=Type=](|v|) is Number,
-                1. If |valtype| is [=i64=], throw a {{LinkError}} exception.
+            1. If [=Type=](|v|) is Number or BigInt,
+                1. If |valtype| is [=i64=] and [=Type=](|v|) is Number,


This seem unnecessarily restrictive. Why not allow a Number to be passed here? The global gets allocated const regardless of the import's declared mutability.

This has been discussed in WebAssembly/JS-BigInt-integration#12; allowing Numbers to be passed is likely to lead to rounding errors. We can revisit if it turns out there is an actual problem in practice.

taralx · 2020-05-11T21:17:19Z

document/js-api/index.bs

-1. If |w| is of the form [=𝖿𝟨𝟦.𝖼𝗈𝗇𝗌𝗍=] |f64|, return [=the Number value=] for |f64|.
+1. If |w| is of the form [=𝗂𝟨𝟦.𝖼𝗈𝗇𝗌𝗍=] |i64|,
+    1. Let |v| be [=signed_64=](|i64|).
+    1. Return a [=BigInt=] representing the mathematical value |v|.


I think it's fine, but it should probably be "... of |v|". The link is https://tc39.es/ecma262/#mathematical-value, if you want to linkify it.

binji

The proposal is officially phase 5 now, so the PR can be merged: see https://lists.w3.org/Archives/Public/public-webassembly/2020Jun/0000.html

ppKrauss · 2020-11-01T14:27:30Z

Hi, this new API will offer some way to obtain the amount of bits of a BigInt?

Perhaps something as integerLogarithmBase2(BigInt)? (not a string conversion to count digits of the bits-string!).

littledan mentioned this pull request Feb 19, 2018

Add BigInt/i64 integration agenda item WebAssembly/meetings#171

Merged

xtuc reviewed Feb 20, 2018

View reviewed changes

jfbastien mentioned this pull request Feb 21, 2018

🛤 JavaScript BigInt to WebAssembly i64 integration WebAssembly/design#1186

Closed

littledan added the enhancement label Feb 21, 2018

littledan mentioned this pull request Mar 2, 2018

Add bigint type whatwg/webidl#525

Merged

littledan mentioned this pull request Jun 24, 2018

[js-api] Allow creating i64 globals #827

Closed

lorenzleutgeb mentioned this pull request Sep 28, 2018

Typed Array: What about i64? tc39/ecma262#1316

Closed

binji mentioned this pull request Oct 16, 2018

🛤 JavaScript BigInt to WebAssembly i64 integration WebAssembly/proposals#7

Closed

ExE-Boss mentioned this pull request Feb 14, 2020

Consider renaming numeric types to match ECMAScript typed arrays whatwg/webidl#843

Open

Merge JS-BigInt-integration proposal into spec

1411462

See the JS-BigInt-integration proposal here: https://github.com/WebAssembly/JS-BigInt-integration

Ms2ger force-pushed the bigint branch from 1f9637b to 1411462 Compare May 11, 2020 14:20

taralx reviewed May 11, 2020

View reviewed changes

fixup! Merge JS-BigInt-integration proposal into spec

7e49cbe

xtuc approved these changes Jun 2, 2020

View reviewed changes

Ms2ger requested a review from binji June 9, 2020 14:25

binji approved these changes Jun 9, 2020

View reviewed changes

littledan merged commit 07a5590 into WebAssembly:master Jun 9, 2020

Ms2ger deleted the bigint branch June 10, 2020 07:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[spec] Normative: Add i64<->BigInt conversion in JS API #707

[spec] Normative: Add i64<->BigInt conversion in JS API #707

littledan commented Feb 17, 2018 •

edited by Ms2ger

Loading

jfbastien commented Feb 17, 2018

littledan commented Feb 17, 2018

jfbastien commented Feb 17, 2018

littledan commented Feb 17, 2018

jfbastien commented Feb 18, 2018

littledan commented Feb 19, 2018

xtuc commented Feb 20, 2018

xtuc left a comment

xtuc Feb 20, 2018

littledan Feb 20, 2018 •

edited

Loading

xtuc Feb 20, 2018 •

edited

Loading

littledan Feb 20, 2018

xtuc Feb 20, 2018

taralx May 11, 2020

Ms2ger May 12, 2020

rossberg commented Feb 20, 2018 •

edited

Loading

littledan commented Feb 20, 2018

jfbastien commented Feb 20, 2018

littledan commented Jun 24, 2018

xtuc commented Dec 18, 2018

xtuc commented Mar 4, 2019

littledan commented Mar 5, 2019

taralx May 11, 2020

Ms2ger May 12, 2020

taralx May 11, 2020

binji left a comment

ppKrauss commented Nov 1, 2020

[spec] Normative: Add i64<->BigInt conversion in JS API #707

[spec] Normative: Add i64<->BigInt conversion in JS API #707

Conversation

littledan commented Feb 17, 2018 • edited by Ms2ger Loading

jfbastien commented Feb 17, 2018

littledan commented Feb 17, 2018

jfbastien commented Feb 17, 2018

littledan commented Feb 17, 2018

jfbastien commented Feb 18, 2018

littledan commented Feb 19, 2018

xtuc commented Feb 20, 2018

xtuc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

littledan Feb 20, 2018 • edited Loading

Choose a reason for hiding this comment

xtuc Feb 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rossberg commented Feb 20, 2018 • edited Loading

littledan commented Feb 20, 2018

jfbastien commented Feb 20, 2018

littledan commented Jun 24, 2018

xtuc commented Dec 18, 2018

xtuc commented Mar 4, 2019

littledan commented Mar 5, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

binji left a comment

Choose a reason for hiding this comment

ppKrauss commented Nov 1, 2020

littledan commented Feb 17, 2018 •

edited by Ms2ger

Loading

littledan Feb 20, 2018 •

edited

Loading

xtuc Feb 20, 2018 •

edited

Loading

rossberg commented Feb 20, 2018 •

edited

Loading