Francis McCabe

to channel Andreas: why? The primary security aim behind the design of wasm is to protect the engine/host from malicious code. As such, the design of wasm is already strong:...

Not sure if this is strictly on point: but automatically converting last calls to tail calls may (will) affect semantics of applications. return_call is useful for so-called tail optimization. But,...

Actually, stack exhaustion, as you put it, DOES count (in languages like Scheme). Other considerations include meta-level features such as dynamic scope, profiling, etc.

Think about the scenario where an exception in one coroutine needs to be propagated to another coroutine -- mediated via teh green thread scheduler.

An additional note: a strictly symmetric design (dare I say bag'o stacks?) would not need to special case exception handling. IMO, whenever a couroutine wakes up from being suspended it...

Suppose a green thread needs to have an exception ... as part of the application logic, not part of the protocol (say). Where does the exception 'come from'? Not the...

At the moment, the return cont type is baked in to the forward cont type: switch $ct1 $e : [t1* (ref null $ct1)] -> [t2*] but, if switch took and...

@tlively The rationale for switch_throw_ref is the same as for resume_throw_ref: to support application patterns involving coroutines communicating with each other. (In general, throwing an exception is simply a form...

@tlively, Well, actually, I was trying to see if a more 'separated' approach could be made to work. In my original formulation for bag of stacks, the return continuation was...

After thinking more, I retract the suggestion to add switch_throw. Since propagating an exception in this way *should* really be part of an application's coroutine protocol. (Note that bag o...