Merge mutable global proposal into spec #814
Conversation
document/core/valid/modules.rst
Outdated
| * Then the export description is valid with :ref:`external type <syntax-externtype>` :math:`\ETGLOBAL~C.\CGLOBALS[x]`. | ||
|
|
||
| .. math:: | ||
| \frac{ | ||
| C.\CGLOBALS[x] = \MCONST~t | ||
| C.\CGLOBALS[x] = \ETGLOBAL~\globaltype |
There was a problem hiding this comment.
No \ETGLOBAL here, CGLOBALS contains plain globaltypes.
|
Squashing sounds okay to me in this case, but we should probably avoid in most other cases. I suggest at least including a link to the other repo in the commit message. |
See the mutable-globals proposal repo here: https://github.com/WebAssembly/mutable-global
|
This merge signifies the first merged feature into the spec interpreter, right? I wonder if it is desirable to provide flags to turn off such features? |
|
@pepyakin, what would that be useful for? We only merge stuff that has been voted into the standard by the WG, so at that point it can be regarded an official feature (and in this case we even decided to slip it into 1.0 as a late addition). The rest is dealt with by versioning of the spec repo, I would argue. |
That would probably suffice for common use cases. To avoid fragmentation, WASM impls need to be able to say they conform to something. After this merge, my impl is now non-compliant. No biggie for this one change, but I hope this is a special case and spec changes in general are part of a separate version. |
|
@cretz IIRC, the long term idea is that WebAssembly will operate much like the JS standard does and implementations can claim they fully support some past year's version of the standard. e.g. Wasm v2.0/Wasm 2019. |
|
That's true. However, there are a few problems with this. This view presumes a linear adoption of the features by the embedders. So if feature A is accepted and then feature B is accepted then implementors will implement them in that order. But that might not be true since some implementations will not support all the features. Another problem is the spec interpreter, and the testsuite can evolve not only regarding features. Bugs can be fixed in the spec interpreter, and new tests might be added. Edit: However, I'm not arguing about the mutable globals propolsal. But about the general mechanism. Although I have the same problem as @cretz. |
|
It's true that implementations may not implement all features from a future version of the spec. By it's nature wasm does not have a good way to test existence of some feature without embedder support. On the web (at least in the near term) this will have to be resolved by feature testing. Other embedders might choose some other mechanism. I don't think the spec interpreter nor its tests are expected to be the source of truth. On the web, for instance, I doubt any implementation would take a bug fix that broke websites, even if that meant differing from the spec repo. |
If it is not, what is the point then? I'm not sure I follow. Let me clarify what my case is. We are using Wasm as a VM for smart-contract execution in a blockchain. It's quite an unusual embedding. It doesn't tolerate any non-determinism (yes, we need to deal with existing non-determinism in Wasm, but that's quite simple). Thus we are not going to implement any feature that might introduce new sources of non-determinism, such as GC (assuming weak refs), threads, etc. Another unusual aspect is that all side-effects produced by the execution cement the logic. If there is a bug that affected a result of the execution, and if the result of this execution is widely accepted, then we need to treat this bug as a part of consensus which is very awkward. Because of this, there is high demand for the high-quality specification and the testsuite. So far, we have successfully been using the testsuite to verify our implementation. I must say it is an invaluable tool. The same goes for the spec interpreter: we have been fuzzing our implementation against it. Having linear versioning, and probably other implementors with similar requirements, will prevent us from using the spec and the testsuite directly. |
|
The spec repo (document, test suite, interpreter) is supposed to be consistent and tests and interpreter thus reflect the source of truth in terms of what's the official standard. An inconsistency between the three would be a bug that, if not obvious, would need to be resolved by the CG. I think @kmiller68 is referring to a different sort of inconsistency, where the spec prescribes one thing but all implementations actually do something else. That is a situation that unfortunately is fairly common in JavaScript, because it is a much more complicated language, with a more hand-wavy definition, where many features have been standardised after the fact. I don't see much risk that we run into a situation like that with Wasm (at least not for the core). But if we did, we might want to decide to change the source of truth, i.e., the spec. With regard to the test suite in particular, I don't think we will ever need to make breaking changes (other than removing some negative tests when we add features). The test suite is agreed upon by all major implementations, so the above scenario cannot really arise. |
|
As for versioning, the idea is that the master branch always has all the latest features. But once we actually release a standard, we will tag it or create a branch. After 1.0 is out you should hence always be able to follow a fixed version of your choice and expect it to not grow additional features. Until 1.0 is fixed the situation naturally is a bit more volatile, but in reality we had a feature freeze long ago. We made an exception for mutable globals because it was a fairly small extension and there was an increasing risk of creating incompatibilities in the JS API if we did it later. See the meeting notes of the May 15 CG meeting. |
This is a late addition to the 1.0 version of the specification (see WebAssembly/spec#814). I took this opportunity to try associating the monad to the interface instances directly. I am not sure this is the best way to do, but let’s try this.
This is a late addition to the 1.0 version of the specification (see WebAssembly/spec#814). I took this opportunity to try associating the monad to the interface instances directly. I am not sure this is the best way to do, but let’s try this.
We discussed this in the June 6 Working Group meeting and decided to merge the mutable-global proposal into v1 of the spec.
Since this proposal doesn't actually change that much, I thought it might be nicer to squash the changes from the mutable-global repo it into one patch. This means we lose the change history here, but it's still available in the mutable global repo, so I think it's OK. What does everyone think?