4 ms·

I first heard of algebraic effects in a presentation about Unison recorded at Strangeloop. Realizing that exceptions, async, generators, and continuations could

• fiddlerwoaroof 3y ago
  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.
• duped 3y ago
  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.
  • lolinder 3y ago
    > 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).
    • duped 3y ago
      My point is that it's incredibly rare to actually need such abstractions.
      • infogulch 3y ago
        Maybe it's worth investing into foundational research, instead of charging anyone who tries to do something new as frivolously chasing their own boredom.
      • TeMPOraL 3y ago
        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.
      • davexunit 3y ago
        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.
  • spankalee 3y ago
    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.
    • vanderZwan 3y ago
      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.
      • infogulch 3y ago
        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.
  • baq 3y ago
    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.
    • mananaysiempre 3y ago
      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.
      • davexunit 3y ago
        Call/cc is generally considered a bad primitive now, superseded by delimited continuations that compose nicely.
        • lapinot 3y ago
          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 https://pauldownen.com/publications/1907.13227.pdf
  • u320 3y ago
    > 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.
• phplovesong 3y ago
  Yes! This is why im super exited about Ocaml 5.0. The ongoing work is now to add typed effects to the typesystem.
• singularity2001 3y ago
  Does this approach avoid function coloring? That is: do legacy calls of functions containing yield instructions just treat these as nop?
  • lapinot 3y ago
    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.
• JaggerJo 3y ago
  Any chance you still know the title of the strangeloop presentation?