Algebraic Effects for the Rest of Us

I was completely baffled by "algebraic effects" for years. They looked far too confusing for me to want to spend my time on them, and took the "Don’t feel like you have to [get curious about them]" approach.

But then at some point it struck me: underlying all these effect systems is just passing stuff in. So I developed my own effect system for Haskell, Bluefin[1], based on capabilities, which means the "capability to perform some effect" is represented by just passing stuff in (that is, a function can do some effect as long as it has been passed the capability to do it).

From this point of view it's hard to understand the excitement over "resume with" and "the part you can’t do with try / catch. It lets us jump back to where we performed the effect, and pass something back to it from the handler". Programming languages have had that feature since forever: a "resumable exception" is a "function call". A dynamically chosen "resumable exception" is the call of a dynamically chosen function, i.e. the argument to a higher order function.

So I don't know why people love the complexity around "algebraic effects". Maybe the mystique has a certain allure. But if you want the most straightforward possible approach I can recommend you try out Bluefin. I'm happy to answer questions on the issue tracker[2].

(Caveat: Bluefin is able to simplify things dramatically by dropping support for "multi-shot" continuations. But mostly you don't want multi-shot continuations.)

EDIT: I was too pessimistic, bazoom42 has noticed this :) https://news.ycombinator.com/item?id=48334067

[1] https://hackage.haskell.org/package/bluefin

[2] https://github.com/tomjaguarpaw/bluefin/issues/new

I’ve used effects in scala3 with cats-effects and haven’t been impressed. All in all, the way it was used was just to reimplement a very similar interface to exceptions.

So this looks like dynamically scoped callbacks. Instead of passing callbacks along as parameters they are declared as “handlers”, and any function down the call stack can invoke them. Is this a correct understanding?

Effect is unreasonably effective. Pun etc.

The problem with these concepts is a) they are completely opaque to the common chud programmer and b) they are just not available to people in languages that anyone actually uses. There are a bunch of effect libraries in Haskell, even special efforts to make them work better in GHC, but it's nearly all wasted effort because it's just academic circlejerk.

Effect brings these capabilities to the masses by implementing them in the most popular programming language on the planet. Obviously, there is quite a learning curve -- it is essentially a programming language unto its own inside another programming language -- but it's doable. I've onboarded juniors with close to 0 FP experience into an Effect codebase. The guardrails help a lot. The language server which helps with best practices, the type errors themselves help quite a lot.

Arguably the best way to do Effect would be a separate programming language, but that would just give us the problems Haskell has: nobody would use since there would be no ecosystem, and there will be no ecosystem since nobody would use it.

Standard feature of Common Lisp condition system (over 30 years old).

https://lisp-docs.github.io/cl-language-reference/chap-9/j-b...