Maybe this is actually what started that proposal, but it sounds very useful to efficiently implement @Frame when using Zig to create WebAssembly modules.
WasmFX: Effect Handlers for WebAssembly
41–44 of 44 posts
Re: WasmFX: Effect Handlers for WebAssembly
#42Earlier quoted context omitted.
WASM is used to implement all kinds of control flow in other languages, so here it makes a lot of sense to have a lower level abstraction. The languages on top of WASM will still have exceptions, generators, etc.
I was thinking the same thing: surely the needs of low-level languages intended as compilation targets are different from languages intended to be programmed in directly? Especially if the goal is to be able to accommodate different high-level language paradigms, which WASM seems to be aiming for.
This is the best argument for a general effects implementation specifically for wasm -- the many languages that target wasm have a wide variety of control flow needs. A generalized solution to this problem has the advantage that it enables different compilers to use effects to match their required control flow semantics, while minimizing the surface area for runtime implementers.
Re: WasmFX: Effect Handlers for WebAssembly
#43Earlier quoted context omitted.
The point, as exhibited by the practical issues around Scheme’s call/cc, is that it can be very hard to make different libraries work together when each of them makes use of such control-flow primitives. It definitely doesn’t happen by default—if you just use them at the same time, the result will run, but it won’t make sense (or obey the individual libraries’ invariants). So if you’re happy to fence off the generali…
Call/cc is generally considered a bad primitive now, superseded by delimited continuations that compose nicely.
Agreed, except if you're willing to go into weird territory and go fully dual, programming terms and continuations alike (Downen & Ariola's great introduction to mu-mu-tilde language, not the earliest, but one of the most readable on the topic, quite mind blowing imho):
Re: WasmFX: Effect Handlers for WebAssembly
#44I first heard of algebraic effects in a presentation about Unison recorded at Strangeloop. Realizing that exceptions, async, generators, and continuations could all be unified and implemented on top of one language feature was mind expanding. It looks like the juicy details are in the Explainer: https://github.com/WebAssembly/stack-switching/blob/main/pro...
Does this approach avoid function coloring? That is: do legacy calls of functions containing yield instructions just treat these as nop?
This will never happen, "legacy call" of functions manipulating the control stack in weird ways can never be meaningful. OTOH the reverse is not always true but a good system should have it: transparent recasting of pure code as effectful code. In other words, the problem that should be solvable but isn't always is that you should be able to "await" a pure function. Or more generally, transparent subtyping of less effectful code into more effectful. Subtyping isn't easy but it's also not impossible if you think about it early enough during the design.