Would it be good to separate out JS specific semantics?

[aardappel]

Reading the overview, I feel this proposal addresses several needs:

• How to specify what all these i32's in wasm import/exports actually mean for a given host embedding. This is definitely very much needed.
• How to do this specifically in the case of JS.
• How to store/refer to host objects that may be referred to by such an i32 (in this case, through extra tables).

And one concern that is I am missing being addressed:

• How to do this for other possible host environments, such as a host that does not have a JS environment, but binds directly to C/C++.

It seems to me that these 4 concerns would be best addressed orthogonally. So far, the wasm spec, while in its primary implementation is intended to be used with JS, has been specified as a very general low-level machine with no dependence on any JS semantics. This proposal could end up adding a lot of JS specifics, which may not serve future uses well, even if optional.

Specifically, I'd suggest:

• Make "JS Bindings" a spec that is entirely separate from the wasm spec, and something only (optionally) relevant to JS hosts.
• Not specify that mapping i32 to object has to go through tables, or how those tables are to be stored in a wasm module. If we have a generic way for embeddings to work with tables, this can still work, but I can imagine a particular embedding (even JS) could instead manage these itself in an array of objects in its managed space, without the need to use wasm tables for this. In the end, an i32 in linear memory will be an unreliable reference, regardless of wether tables are used or not.
• Have a universal host bindings spec that talks about things that may concern any possible embedding / host language. Things like how to copy memory in both directions, and how to interface with wasm allocators may be universal.
  • We could even try to define ways of accessing data on both sides of the fence that are universal across possible embeddings, by making it very low level (allowing to specify exact memory layout and alignment). This is of course very tricky, given that I can think of endless ways a host or wasm program could define what it means to be a "string" etc. And of course, different language implementations may have different representations. Probably not practical, just throwing it out there..
• Have at least one other specific embedder bindings spec, to be able to contrast with JS-specific bindings and what we think are universal binding concerns. Bindings typical to C/C++ hosts would seem a logical addition to me, but maybe there are other examples. Again, entirely optional, but very helpful to create an eco-system of shared APIs across different embeddings.

[magcius]

Not specify that mapping i32 to object has to go through tables, or how those tables are to be stored in a wasm module. If we have a generic way for embeddings to work with tables, this can still work, but I can imagine a particular embedding (even JS) could instead manage these itself in an array of objects in its managed space, without the need to use wasm tables for this.

What do you mean by this? Tables are a wasm-side feature, not an embedding-side feature, and there's plans to introduce opcodes that allow wasm to copy elements from one table index to another. What do you propose these i32 values mean if not indexes into tables, and how do you propose wasm code manages them?

[aardappel]

@magcius Yes, exactly, I advocating to keep wasm-side and embedding-side (JS) cleanly separated, which I don't feel this is doing.

Enabling wasm to copy a host object can be done in all sorts of ways and does not need to be coupled with the table mechanism necessarily. Certainly adding opcodes to wasm that are specific to bindings of a particular language/embedding does not sound desirable to me.

[rossberg]

I believe the current idea is that this host binding spec is JS-specific and becomes part of the JS API spec.

Identifying and factoring out non-JS parts seems like over-engineering at this point. For one, we don't have any experience with other embeddings, so it's hard to predict what parts (if any) of the binding stuff is universal. We can always refactor specs once other bindings appear and enough common ground materialises, but for now I would just stick to keeping it simple.

[pchickey]

Closing as fixed: the current proposal, which has evolved a lot since this issue was opened, is no longer bound to JS specific semantics