Andreas Rossberg

@lukewagner, yes, and the definition of candidate executions relies on agents, which "comprise a set of ECMAScript execution contexts, an execution context stack, a running execution context" etc. All of...

@jfbastien, well, without a suitable Wasm definition of agent that connects it to Wasm execution the definition of execution order is totally vacuous. It wouldn't specify anything about the behaviour...

@syg, I see a number of issues and mismatches between the two languages. For example, off the top of my head: - The definition of "agent" (as well as execution...

PS: For the experts, the primary mismatch probably boils down to ES defining (essentially) a big-step semantics, while Wasm is using a small-step semantics. The problem with big-step is that...

@syg summed it up nicely. Here are some additional details of our discussion (@syg and @lukewagner correct me if I'm wrong). There are two properties of the Wasm core spec...

@MaxGraey, it's not enough that the producers prove such properties statically. They need to convey those proofs to the engine, e.g. via the type system, such that the engine can...

From @aheejin's list, I think (2) is by far the most attractive option. > 1. Make all traps catchable I agree this isn't a good idea, and as @aheejin points...

> It doesn't have to be an exception handler. If we have thread-local variables, we could have a control flow construct that introduces a `let`-like scope, assigning a value to...

This is not a bad idea. It is one step further in the direction of a union type -- really, `(ref null i31 $t)` is `(ref (union null i31 $t))`....

Yes, that's one obvious use case. Although you can easily find similar use cases for other kinds of small unions, so that alone isn't necessarily enough to justify special casing...