Why Algebraic Effects?

I believe this can be done statically (that's one of the key points of algebraic effects). It works work essentially the same as "jump to caller", where your ide would give you a selection of options, and you can find which caller/handler is the one you're interested in.

All of what you state is very doable.

I think this is a part of the point: we are able to simply write direct style, and not worry at all about the effectual context.

> how do you find the code that will run when they do fail

AFAIU, this is also the point: you are able to abstract away from any particular implementation of how the effects are handled. The code that will when they fail is determined later, whenever you decide how you want to run it. Just as, in `f : g:(A -> B) -> t(A) -> B` there is no way to find "the" code that will run when `g` is executed, because we are abstracting over any particular implementation of `g`.

I work in a .NET world and there many developers have this bad habit of "interface everything", even if it has just 1 concrete implementation; some even do it for DTOs. "Go to implementation" of a method, and you end up in the interface's declaration so you have to jump through additional hoops to get to it. And you're out of luck when the implementation is in another assembly. The IDE _could_ decompile it if it were a direct reference, but it can't find it for you. When you're out of luck, you have to debug and step into it.

But this brings me to dependency injection containers. More powerful ones (e.g., Autofac) can establish hierarchical scopes, where new scopes can (re)define registrations; similar to LISP's dynamically scoped variables. What a service resolves to at run-time depends on the current DI scope hierarchy.

Which brings me to the point: I've realized that effects can be simulated to some degree by injecting an instance of `ISomeEffectHandler` into a class/method and invoking methods on it to cause the effect. How the effect is handled is determined by the current DI registration of `ISomeEffectHandler`, which can be varied dynamically throughout the program.

So instead of writing

    void DoSomething(...) {
        throw SomeException(...);
    }

    void DoSomething(IErrorConditions ec, ...) {
        ec.Report(...);
    }

Sounds like you're just criticizing try-catch style error handling, rather than criticizing algebraic effects specifically.

Which, I mean, is perfectly fair to not like this sort of error handling (lack of callsite indication that an exception can be raised). But it's not really a step backward from a vast majority of programming languages. And there are some definite upsides to it as well.

That's part of the point: it's dynamic code injection. You can use shallow- or deep-binding strategies for implementing this just as with any dynamic feature. Dynamic means just that bindings are introduced by call frames of callers or callers of callers, etc., so yes, notionally you have to traverse the stack.

> And this cannot be done statically (i.e. your IDE can't jump to the definition),

Correct, because this is a _dynamic_ feature.

However, you are expected not to care. Why? Because you're writing pure code but for the effects it invokes, but those effects could be pure or impure depending on context. Thus your code can be used in prod and hooked up to a mock for testing, where the mock simply interposes effects other than real IO effects.

It's just dependency injection.

You can do this with plain old monads too you know, and that's a much more static feature, but you still need to look way up the call stack to find where _the_ monad you're using might actually be instantiated.

In other words, you get some benefits from these techniques, but you also pay a price. And the price and the benefit are two sides of the same coin: you get to do code injection that lets you do testing and sandboxing, but it becomes less obvious what might be going on.

I have to admit I don't understand the second point. If you could statically determine from the definition of foo and bar what code handles their errors, than there would be no reason for foo or bar to error, they could just call the error handling code. If foo and bar return Result sum types and my_function just passes those errors up, it would be no different. You don't know what callers of my_function would do with those errors.

If that's what you're looking for you might want to try my Haskell effects library Bluefin (it's not an "algebraic" effects library, though). The equivalent code would be

    myFunction :: e :> es -> Exception String e -> Eff es r
    myFunction ex = do
      x <- LibraryA.foo ex
      y <- LibraryB.foo ex
      z <- LibraryC.foo
      ...

It also answers the second part of your question: the code that runs on failure is exactly the code that created the `Exception String` handle. Any exception arising from that handle is always caught where the handle was created, and nowhere else. For example, it could be here:

    try $ \ex -> do
        v <- myFunction ex
        ...

    myFunction :: e :> es -> Exception String e -> Eff es r
    myFunction ex = do
      catch
        (\ex2 -> do
          x <- LibraryA.foo ex
          y <- LibraryB.foo ex2
          z <- LibraryC.foo
          ...)
        (\errMsg -> logErr errMsg)

Let me know what you think!

I don't see how this is different from traditional programming.

> I do think this is a really neat concept, but I have major reservations about the readability/debuggability of the resulting code.

I don't think that readability will be harmed, but I can understand your concerns about debugging. I feel that cluttering the code with consistency/error checks everywhere actually harms much more readability.

This is not a meaningful drawback. It's 2025. IDEs have existed for almost half of a century. Crippling programming languages because you want to shove everything into the source code (in a text-based format no less) is insane. Let's actually try to move programming into the 21st century, please.

> And this cannot be done statically (i.e. your IDE can't jump to the definition), because my_function might be called from any number of places, each with a different handler.

This is wrong. Your IDE can find call sites, build a call graph, and show you the places (parents in the call graph) where an error might be handled for a particular function.

It think it's about static vs. dynamic behavior.

In monadic programming you have to implement all the relevant methods in your monad, but with effects you can dynamically install effects handlers wherever you need to override whatever the currently in-effect handler would be.

I could see the combination of the two systems being useful. For example you could use a bespoke IO-compatible monad for testing and sandboxing, and still have effects handlers below which.. can still only invoke your IO-like monad.

They have enjoyed popularity amongst the Scala FP minority.

They are not broadly popular as they come with an unacceptable amount of downsides i.e. increased complexity, difficult to debug, harder to instantly reason about, uses far more resources etc. I have built many applications using them and the ROI simply isn't there.

It's why Odersky for example didn't just bundle it into the compiler and instead looked at how to achieve the same outcomes in a simpler and more direct way i.e. Gears, Capabilities.

If you're limiting yourself to just a single effect there's probably not much difference, however once you have multiple effects at the same time then explicit support for them starts to become nicer than nesting monads (which requires picking an order and sometimes reorder them due to the output of some functions not matching the exact set or order of monads used by the calling function).

Couldn't the plumbing be reduced significantly through type inference? I.e. the function that invokes an effect will need the signature, the callers higher up the chain won't.

Also, even if you had to adapt all the signatures, at least you wouldn't have to adjust the call sites themselves to pass in the context every single time.

Not quite. setjmp/lonjmp as they exist in C at least can jump up the call stack but not back down. I mention this at the end of the article but each language implements algebraic effects differently, and efficiency has improved in recent years. Languages can also optimize the effect differently based on how the handler is defined:

- Handlers which are tail-resumptive can implement the effect as a normal closure call.

- Handlers which don't call resume can be implemented as an exception or just return an error value at every step until the function exits the handler.

- Handlers which perform work after resume is called (e.g. `| my_effect x -> foo (); resume (); bar ()` can be implemented with e.g. segmented call stacks.

- Handlers where resume is called multiple times need an equivalent of a delimited continuation.

Another way to implement these generally is to transform the effects into monads. For any set of effects you can translate it into a monad transformer where each effect is its own monad, or the free monad can be used as well. The cost in this approach is often from boxing closures passed to the bind function.

Koka has its own approach where it translates effects to capability passing then bubbles them up to the handler (returns an error value until it gets to the handler).

With just a few restrictions you can even specialize effects & handlers out of the program completely. This is what Effekt does.

There really are a lot of options here. I have some links at the end of the article in the foot notes on papers for Koka and Effekt that implement the approaches above if you're interested.

Sometimes making these parallelism hurts more than not having them in the first place

It's interesting to see how things can work if the language itself was designed to support dependency injection from the get-go. Algebraic effects is one of the ways to achieve that.

1) Testing. Write pure code with "effects" but, while in production the effects are real interactions with the real world, in testing they are mocked. This allows you to write pure code that does I/O, as opposed to writing pure code that doesn't do I/O and needs a procedural shell around it that does do the I/O -- you get to write tests for more of your code this way.

2) Sandboxing. Like in (1), but where your mock isn't a mock but a firewall that limits what the code can do.

(2) is a highly-desirable use-case. Think of it as a mitigation for supply-chain vulnerabilities. Think of log4j.

Both of these are doable with monads as it is. Effects can be more ergonomic. But they're also more dynamic, which complicates the implementations. Dynamic features are always more costly than static features.

This is just like the story of the blind men with the elephant. The elephant (algebraic effects) is a whole other different beast, but to help the beginner understand the first parts of it, we say the truck is like a snake (resumable exceptions) or that the ear is like a fan (dependency injection).

Algebraic effects are a new type of control flow. When an effect is raised, the handler (defined further up the call stack) has several options:

- handle the effect and resume the computation where the effect was raised.

- handle the effect, but resume the computation multiple times back to where the effect was raised.

- decide not to handle the effect, and just exit, at which point the execution resumes right when the handler was called further up the stack, and everything executed since then is as if it never happened. This is a way of doing back tracking.

In addition, what's algebraic about algebraic effects is that they usually come in a group, and are designed with a compositional algebra, so you can safely compose them in different ways. A common one is commutativity, so it doesn't matter what order you execute them in. Of course, not all algebraic effects have commutativity, as that has to be designed by the implementer. Monads are different in that they often don't compose without monad transformers, so that can be finicky.

Hence, with all these things together, you can use them to implement control flow in other languages that are typically baked into the language, such as exceptions, coroutines, generators, async/await, probabilistic programming, backtracking search, dependency injection. You might also invent your own!

But most commonly here, we use them to separate the *intent* to do a side-effect from the actual execution of the side-effect. That way, side-effects are controlled, and it becomes easier to reason about our code.

Algebraic Effect is a variant/enhancement of dependency injection formalized into a language. Dependency injection has massive usage in the wild for a long time with just library implementation.

React hooks are different from full-blown algebraic effects in a couple ways:

- The handler for the hooks are already implemented for you, and you can't swap it out for a different handler. For example, the implementation of useState is fixed, and you can't swap it out for a different implementation.

- They're not multishot resumption. When a hook is raised, the handler can only handle it and resume it once. In a full-blown algebraic effect, the handler can resume the same raised effect multiple times.

- Algebraic effects usually come bundled together. Those effects have specific compositional rules with each other. That's how they're algebraic.

[1] https://www.youtube.com/watch?v=G_jp87gxILE [2] https://motioncanvas.io/

For example, a function annotated with say `query_db(): User can Datebase` means the function can call database and the caller must provide a `Database` handler to call the `query_db`.

The constraint of what can do and not is pretty popular in other programming fields, most notably, NextJS. A server component CANNOT use client feature and a client component CANNOt access server db.

Personally, I don't see a whole lot of value in that, with how unpredictable execution could get. I'd rather write a function that explicitly returns another function to be called multiple times. (Or some equivalent, e.g., a function that returns an iterator.)

of course I am hoping to get corrected on this.

Think of it more like an interface. It turns out that many common patterns - async, IO, yielding can all be expressed with a handle - and the effect can be represented in the signature.

This allows the code to have which effect its ran in, at runtime - other commenters pointed out its very similar to dependency injection.

- Only your outermost application entry-point will need to stack all effects; you'll wire the server, client, DB and so on in your `main` method that returns Unit \ (IO & Abort & Result & Transaction & Env ...). In specific modules individual functions should use only the narrowest effect.

- Good ergonomics for type polymorphism and type inference are obviously paramount to adding algebraic effects in a way that is minimally invasive. It's obviously not trivial and mostly a PL research field at this point, but existing implementations show that there's potential for better DX compared to alternatives (monadic effect systems, mostly).

It would be cool to see how generators will be implemented with algebraic effects.

But yes, you can implement single-shot effects with generators.

Shows clearly why they will never be a mainstream concept. The value proposition is only there when you have more elaborate concurrency needs. But that is a tiny fraction of the applications most people are writing today.

Do you also feel like effect is “or or nothing”? Or could you enclose certain parts of a program into effect parts?

Full-blown algebraic effects are multi-shot, meaning that you can "resume the thrown exception" multiple times. The only way to do that is through delimited continuations, which isn't available as a feature in most languages, and can't be emulated by other language features--unless you reimplement the call stack in userland.

In addition, the handler can decide not to resume a raised effect at all, at which point it can exit. When it does, it's as if all the computation that it did when the handler wrapped the computation didn't happen at all. It's a way of doing backtracking. This is also possible due to delimited continuations.

Both are things that you can't do in the effects library.

The "algebraic" part of algebraic effects is that the effects also come with implicit compositional rules that say how you can put them together. You can design a family effects with rules like commutativity and associativity, so that you can be sure of how to compose them.

I can’t have a hook that talks to a real API in one environment but to a fake one in another. I’d have to use Jest style mocking, which is more like monkey patching.

From the point of view of a React end user, there’s also no list of effects that I can access. I can’t see which effects or hooks a component carries around, which ones weren’t yet evaluated, and so on.

What about state modified via closures?

Or is it only for system side-effects like filesystem operations?