Hacker News Reader

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.

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

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

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