-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce evaluation as a semantic phase? #1
Comments
I think it's clear enough to me. To avoid any confusion, are you suggesting to mention that's "unlike ES modules"? |
No, the suggestion isn't to make a distinction between WASM modules and ES modules. It's more about the fact that this proposal will introduce the concept of separate instantiation and evaluation to wasm. In the presentation, I explain how evaluation would work for WASM ES modules. Basically, it just means having the start function run in a separate phase from instantiation. So the question in this issue is whether we should treat evaluation as a subtask of instantiation (which could be confusing to anyone who is familiar with the ES module spec), or call it out as its own phase. |
@linclark, the start function and segment initialisation will continue to run as part of the WebAssembly.instantiate function and friends. Hence treating it as a subphase of instantiation is the only possible refinement AFAICS, ES modules notwithstanding. |
Just to make sure I understand, if we are copying the imported values (instead of live binding), it will be done at the call of the the start function and segment initialisation? One other input on that, in Webpack we are modifying the start function into an exported one. That turns out to be more flexible. Maybe we could have a similar API or something. |
@xtuc I think we may be picking up on the same thing here, which is the issue I describe below... @rossberg I want to check my assumptions first. Let me know if you think any of these assumptions are incorrect.
Here’s the issue I see if those assumptions are correct. Let’s say a wasm module imports a function from a JS module. First the JS module instantiation happens, and then the wasm module. The wasm module runs its If we don’t create a separate evaluation phase, do we have to forbid using JS imports in |
@linclark yes sorry, we're indeed on the same page. Your assumptions and the issue you're describing are correct to me. A side note; the
I don't think forbidding would be that easy because you will have to check for things like the following example: (module
(import "a" "b" (global i32))
(global i32 (get_global 0))
) |
I forgot that we already did decide that importing values from JS wouldn't work in the short term. I updated the assumptions to reflect that. However, even with this it still seems to me that we'd want to delay having the |
@linclark, ah, sorry, my comment was more one about terminology, i.e., that in terms of the description of semantic phases you cite and how they're presented to users, module initialisation ("evaluation") is a subphase of instantiation. This is true even from a JavaScript perspective, where the API already exposes an ES modules are special in that they will perform the two subphases of Wasm's module instantiation (allocation and initialisation) in a staged manner. But that is mostly a technicality, in practical terms they are still tied together, i.e., a user cannot invoke them separately, so doesn't need to worry about the phase separation. So in brief, I think all is a fine. The technical changes are no problem and don't require any conceptual changes. |
One thing to keep in mind is that Also the ImportObject must be passed before. |
The core spec explicitly lists the semantic phases.
These are currently:
Given that ES modules have separate instantiation and evaluation phases, should this section make note of this separation?
The text was updated successfully, but these errors were encountered: