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:
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.
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.
> 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).
Maybe it's worth investing into foundational research, instead of charging anyone who tries to do something new as frivolously chasing their own boredom.
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.
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.
> 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.
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.
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):
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.
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.
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?
Maybe this is actually what started that proposal, but it sounds very useful to efficiently implement @Frame when using Zig to create WebAssembly modules.
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.
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.
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.
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.
It looks like the juicy details are in the Explainer:
https://github.com/WebAssembly/stack-switching/blob/main/pro...