WasmFX: Effect Handlers for WebAssembly | Hacker News Reader

WasmFX: Effect Handlers for WebAssembly

wasmfx.dev

146 pointsBentonE41 comments

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

Algebraic effect and delimited continuations have equivalent power. I think, for example, GHC added delimited continuations, in part, because they made it easier to implement algebraic effects efficiently.

The problem with abstracting control flow has always been the ease of composition within a program. I'm not sure if algebraic effects make that better, although I like the simplest form (exceptions with resume) for error handling.

It's kind of like abelian groups and hyper graphs. They generalize many domains very nicely, and are an attractive abstraction. But it turns out they're too abstract for any individual domain, and don't make life easier. The PL world seems to have learned that lesson from call/cc, but I don't know if they've reached it yet with algebraic effects - although it seems looming.

Control flow is sexy for PL researchers, so it makes sense why it's hot right now. Faster matrix multiplications are much more boring, no matter how much better they make society than weird control flow.

Just personally, I can count on one hand the number of algorithms I've written where weird control flow was necessary to make the algorithm easier, and they were all weird shit that I expect other people to use libraries for in most cases.

> they were all weird shit that I expect other people to use libraries for in most cases.

The theory with algebraic effects is that you'd use them to implement those libraries. Most application code won't be implementing new types of effects, but exceptions, generators, async, and who knows what else can be implemented at the library level instead of the language level.

In theory it's a single abstraction that can be implemented once in the language and then all the more complicated abstractions can be swapped out as desired, rather than the current status quo where everyone has to use whatever patterns the language designers chose (which are often rather contentious).

My point is that it's incredibly rare to actually need such abstractions.

Maybe it's worth investing into foundational research, instead of charging anyone who tries to do something new as frivolously chasing their own boredom.

But then, there is a need to make the noise generated by error handling, async, generators, etc. to disappear. Though I doubt it's doable with our current paradigm; we're pushing against the limit of working directly with plaintext, single-source-of-truth code.

I use delimited continuations all the time if the language exposes an interface for them. Coroutines are great to have around. I also use async/await whenever I have to write JS. Seems this proposal really covers the bases for control flow which is great.

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.

But that’s the point…? it’s webassembly not JavaScript or Python. You aren’t really expected to write any of this by hand, even if it’s basically what async functions do under the hood when you type await whatever.

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 generality at the language-implementation level and only ever use one language at a time, there’s no problem. Even if you’re fencing it off at the ABI level it could work, though practical implementations of that are between sparse and nonexistent. But if you’re allowing the user (libraries?) to actually make use of the platform—and anything else feels like a disservice to me—you’ll have to confront the (non-)composability problem.

At the same time, I have to note that algebraic effects were explicitly conceived as a more composable primitive (compared to monad transformers, initially). I can’t see how they’d solve the finally/dynamic-wind problem, for example, but I haven’t looked into them that deep, either, and given their designers are not ignorant of all this, I’m curious to see what they came up with.

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

https://pauldownen.com/publications/1907.13227.pdf

> Just personally, I can count on one hand the number of algorithms I've written where weird control flow was necessary to make the algorithm easier, and they were all weird shit that I expect other people to use libraries for in most cases.

Async/await or error handling is not "weird control flow". In many codebases you would have more functions that use those than not.

Yes! This is why im super exited about Ocaml 5.0. The ongoing work is now to add typed effects to the typesystem.

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.

Any chance you still know the title of the strangeloop presentation?

Enjoyed the linked (more detailed) explainer: https://github.com/WebAssembly/stack-switching/blob/main/pro...

This is an exciting proposal. We have delimited continuations in Guile Hoot, a Scheme to WASM compiler, but because there's no stack switching there's more overhead than there should be.

The moment I saw "continuations" I wondered if it was a proposal by some of the Spritely Institute people partially for the sake of Hoot! But your reply suggests it's not?

Nope, not by us, but we are keeping our eye on it!

I recently gave a talk on delimited continuations for anyone curious https://youtu.be/uRbqLGj_6mI?si=cOqlJighLJE42c-Q

Maybe this is actually what started that proposal, but it sounds very useful to efficiently implement @Frame when using Zig to create WebAssembly modules.

could exception handling be implemented with this? if so would that make the exception handling proposal superfluous?

> could exception handling be implemented with this?

Yes.

> if so would that make the exception handling proposal superfluous?

The exception handling proposal is a subset of this proposal. This proposal doesn't replace it, it completes it.

WebAssembly is getting more complex bit by bit...

That's okay; _using_ WebAssembly is getting easier bit by bit. Features like this one allow the high level programming language features you know and love to be implemented efficiently behind the scenes.

But they make making WASM implementations harder to make.

Useful things are hard to make.

That's how the core has to be, like Vulkan, making the core harder allows for more control, a better foundation. Then we load up those core libraries with easy APIs that are super powerful and can do what was never thought possible.

Same for WebGPU.

So I think WASM is doing this exactly the right way as long as it stays powerful and flexible at the core.

If you are talking about things like the garbage collection, yes, but this proposal is trivial to implement.

People said this about GC but then I implemented a WASM interpreter with GC support and it wasn't very hard to do. This FX proposal would introduce... 6 more instructions I think? Not bad. Especially compared to something like the SIMD extension which feels like it's adding a million instructions.

This is just a proposed extension.

Along with exception handling, I think a stack switching feature like WasmFX will complete WebAssembly's set of control abstractions, so at least that part won't keep growing without bound.

the monika 'fx' is often used by graphics pipelines or rendering to mean special effects, and thus often take on the connotation of being related to graphics or rendering (e.g., javaFX).

I dont think wasmfx should use this monika, as it makes it sound more graphics related than it really is. Naming and connotation of a name is important, as it frames the way people think about things.

Audio, too.

Do you mean 'moniker'?

I think that the word "effects" might be too wide a term even in the domain of programming languages.

There are languages with (side-)effect annotations that have no continuation-like constructs whatsoever.

Reply on news.ycombinator.com