Open and Closed Effect Systems
— 2025-05-22

When discussing effect systems in the context of production programming languages, I believe that the most important distinction is whether effects are purely defined by the language, or whether users are also able to define them. When Magnus Madsen from the Flix programming language joined the Rust T-Lang call for two sessions last December, he used the terms “open” and “closed” to describe this distinction:

• Closed effect systems: are systems where all effects are all defined by the language as built-ins. The number of effects may grow over time, but effects are only ever defined by the language itself. This makes the number of possible effects bounded.
• Open effect systems: allow users of the language to also define their own control-flow effects, which exist alongside the language built-in effects. This makes the number of possible effects unbounded.

The most interesting effects in programming languages have to be built-in. This includes things like controlling whether a function guarantees it will terminate (“divergence”). Or whether a function is allowed to perform side effects (“purity”).

This is different from user-defined effects. These are typically defined using “algebraic effect handlers”, but I’ve also seen the term “typed continuation” used ¹. I think of these more or less as language-level support for thoroughly typed iterators/generators/coroutines. It doesn’t really make sense to express “divergence” using iterators. Which is why even though all effect handlers are effects, not all effects are expressed using effect handlers.

In the context of Rust all we’re discussing right now is the introduction of a closed effect system. And that’s not because we don’t think an open system would not be useful or good. But because formalizing and generalizing Rust’s effect system in a backwards-compatible way is an incredible amount of work already. And in order to ship, we have to draw the line somewhere ².