Introduce evaluation as a semantic phase? about esm-integration HOT 9 CLOSED

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

1. We want to allow wasm modules to depend on JS modules
2. These wasm modules can import both functions and values from JS modules
3. These imported valuesfunctions can be used in the start function
4. You’re suggesting that when the loader instantiates the module by calling record.Instantiate(), it should call the current instantiate function, which will also run the start function. Then record.Evaluate() would be a no-op for wasm modules.

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 start function, which depends on the JS function. But since none of the JS modules have evaluated yet, any value imports that JS function uses would not be instantiated yet.

If we don’t create a separate evaluation phase, do we have to forbid using JS imports in start functions?

from esm-integration.

@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 instantiate function based on this assumption. For better or worse, the terminology here is slightly different from ES modules (I think what ES calls module instantiation Wasm calls module allocation).

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.

from esm-integration.

Conceptually, the semantics of WebAssembly is divided into three phases. [...]

I think it's clear enough to me. To avoid any confusion, are you suggesting to mention that's "unlike ES modules"?

from esm-integration.

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.

from esm-integration.

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

from esm-integration.

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.

from esm-integration.

@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 ToWebAssemblyValue will coerce the undefined value to 0, which will be confusing for many developers.

If we don’t create a separate evaluation phase, do we have to forbid using JS imports in start functions?

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

from esm-integration.

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 start function run, because the start function could potentially run a function imported from JS. That JS function could itself depend on value imports from other JS modules, which wouldn't have been evaluated yet.

from esm-integration.

One thing to keep in mind is that instantiateStreaming is the recommend way and will be used in Webpack anytime soon. Using this method we are not able to call the instantiation explicitly.

Also the ImportObject must be passed before.

from esm-integration.