[spec] List standards depended on

[rossberg]

Adds a short section to the introduction that lists IEEE 754 and Unicode as the external standards that this spec depends on.

[jfbastien]

We should pin specific versions of these specs, no?

[rossberg]

@jfbastien, good question. Currently, I link to the latest Unicode, here and everywhere else. That is, I intentionally avoid pinning. Ecma 262 has started doing the same recently, because that's more desirable than having to update the spec constantly. For IEEE I don't know of such a persistent reference, unfortunately.

(Technically, the versions of the standards are unlikely to really matter much, since the parts that Wasm uses are unlikely to change.)

[jfbastien]

For Unicode I think it's OK, but I think this should be a thing we bring to the WG and poll.

For IEEE-754 I don't think it's OK. @sunfishcode may know better, but IIRC some of it is changing? Something about min / max / minnum / maxnum? We've specified IEEE-754 2008 in prior documents, so it seems safer to go with this for now, figure out if it's OK to just float instead, and based on these facts take a poll.

So I'm OK with committing this as-is for now, contingent on a poll being taken. Could you add it to the agenda for the upcoming call once Brad checks it in?

[jfbastien]

Actually, for Unicode can we spec it as: it's implementation-defined which Unicode spec an implementation adheres to. It shall be minimum Unicode some version. As new things get added we can bump the minimum, but basically we're telling people "use new codepoints at your own risk, older ones should work".

[sunfishcode]

The latest drafts of IEEE 754-2018 do remove minNum, maxNum and related functions which are in IEEE 754-2008. However, WebAssembly avoided defining those specific operations, so it isn't affected.

[jfbastien]

@sunfishcode would you then recommend that we pin to 2008, or that we let it float (haha, float)?

[sunfishcode]

I prefer pinning here. I guess the spec ought to also cite the specific sections and concepts of IEEE 754 (and Unicode) that it has copied from, and then a pinned version would keep those citations valid over time.

The spelling is "IEEE 754-2008" (note the position of the dash).

[jfbastien]

OK that sounds good to me. I do think we want to make this an explicit decision through a vote at some point.

IEEE -1254 ? 😉

[binji]

IEEE -1254

I think that's an illegal constant folding... :-)

[rossberg]

@jfbastien, a minimum version is exactly what Ecma moved away from regarding Unicode, to reduce unnecessary coupling and churn. Why do you suggest we should go the opposite direction?

I guess pinning has less impact for IEEE, though I'd like to understand why it would be an advantage either. @sunfishcode, is IEEE not intended to remain backwards compatible, at least as far as the basic format goes?

[jfbastien]

@jfbastien, a minimum version is exactly what Ecma moved away from regarding Unicode, to reduce unnecessary coupling and churn. Why do you suggest we should go the opposite direction?

I'm suggesting that we understand why Ecma did so for Unicode, and figure out whether it applies to WebAssembly. The same should be done for IEEE 754. Once we have these facts I suggest we explicitly vote on a direction, so that this issue is put to rest, unless new data is presented.

[rossberg]

@jfbastien, I was present in that discussion, and IIRC, it was to avoid having to change the language standard every time Unicode adds another set of emojis. You could argue that a minimum version never needs updating, but in practice, you don't really want to refer to an outdated standard, so it was constantly bumped anyway. (Also, there can occasionalyl be changes that actually affect JS, but I don't think they apply to Wasm.)

[jfbastien]

@jfbastien, I was present in that discussion, and IIRC, it was to avoid having to change the language standard every time Unicode adds another set of emojis. You could argue that a minimum version never needs updating,

If that's the only reason then it's fine with me to float the Unicode version. I'd like a link to the discussion, and some evidence that Ecma believes Unicode intends to evolve in a backwards-compatible manner.

Floating the version doesn't prevent us from mandating a minimum version, which we should also discuss and vote on.

but in practice, you don't really want to refer to an outdated standard,

Why?

Contrast to C++ where we do, it's a small pain in the ass but every time we do an update it forces us to examine what's changed in the spec we're updating and inevitably leads to changes to C++. I agree that it sometimes causes weird inconsistencies, but eventual consistency through forced updates has worked pretty well.

A concrete example: updating C++17 to point at C11 instead of C99 had a bunch of follow-ups. One of them changes how C++ deals with signal handlers. I was heavily involved in this, it's not perfect yet, but the update acted as a great forcing function to get the ball rolling.

The C / C++ relationship is obviously more complex (_Complex?) than WebAssembly and Unicode! What I'm getting to is that I want us to rationalize why we want to float a version, and what the upsides and downsides will be. If Unicode explicitly says that they'll only add previously-reserved codepoint with values up to 0x10FFFF then it seems pretty straightforward to float the version. Is that the case? We shouldn't just guess that it is. Ecma presumably looked into it, there's a record of that conversation, let's link to it and vote if we're satisfied.

[sunfishcode]

As far as I can predict, neither Unicode nor IEEE 754 is likely to change in ways that directly impact WebAssembly core for the foreseeable future, either positively or negatively. Consequently, I think either approach is workable.

I gave my reason for preferring pinning already.

[rossberg]

I factored all links to external standards into suitable macros, which should allow updating them in one place. I also added section info, as suggested by @sunfishcode (even though that has the opposite effect).

@jfbastien:

Why?

AFAIR, some people desired to stay up to date, even when there was no strict technical need, so the minimum version was bumped repeatedly. There are understandable reasons for that, e.g, save readers from having to deal with old (and thus, multiple) spec versions and map back and forth to the current version they probably use elsewhere. Also, I think there was a desire to not make 262 look old.

My take is that you only want to pin when there are concrete dependencies on features that are likely to change. If not, then it seems preferable to decouple versions as much as possible. It reduces churn for the spec and allows implementations to advance versions independently, which allows them to move faster.

For example, if we pinned a certain Unicode version for Wasm, then strictly speaking, we may force an engine like V8 to ship with two instances of ICU occasionally, because for JS they likely always want the latest. Of course, no implementer in their sane mind would sign up for that, so such a spec strategy seems at odds with reality.

Specifying a minimum would be middle ground, but still has the minor social disadvantages mentioned above.

[jfbastien]

@rossberg-chromium yes, I think you've accurately summed up things. Two versions of ICU would be quite silly indeed.

I think we're still missing data to make our decision though: when we poll this we need precedent (notes from TC39) and / or a policy from each standard saying what kind of breaking change they plan to make (if any, either explicit or implicit e.g. minnum / maxnum changes). If this doesn't exist then it's useful data on its own, and I want to record this as part of our vote (so if it changes, we can revisit).

Can you get this data and move this poll forward at the next video call (or a subsequent one)? The patch LGTM with the understanding that we'll discuss and vote on this.

[rossberg]

@jfbastien, I created #566 to track this question separately. I'll see what info I can dig up. In the meantime, feel free to approve this PR. :)

[jfbastien]

Great, thanks! I added it as a future topic for meetings.