Algebraic Effects
Algebraic effects are a programming language abstraction for representing and controlling computational effects — state, exceptions, non-determinism, input/output, concurrency — as algebraic operations that can be intercepted and reinterpreted by handlers. Introduced by Plotkin and Power in 2002 and later extended with handlers by Plotkin and Pretnar in 2009, the algebraic effects framework treats effects not as built-in language features or monadic encodings but as user-defined operations with a clean equational theory.
The core insight is that computational effects can be described by operations (the things a computation can do) and equations (the laws those operations satisfy). An effect is algebraic when its operations commute with sequencing — that is, when the order of performing an effect and then continuing a computation is itself a well-defined operation. This seemingly technical condition has profound consequences: it means effects can be composed, transformed, and intercepted without losing their structural properties.
Effects as Operations, Not Monads
In the traditional Haskell approach, effects are encoded using monads: the State monad for mutable state, the Maybe monad for exceptions, the List monad for non-determinism. Each monad wraps a computation in a type that sequences operations according to the monad's bind rules. This approach is powerful but suffers from a composition problem: combining multiple effects requires monad transformers, and the resulting tower of transformers becomes unwieldy as the number of effects grows.
Algebraic effects solve this by decoupling the definition of an effect from the definition of its handler. A computation performs effects by invoking operations — like `get()` for reading state or `throw(e)` for raising an exception — without knowing how those operations will be interpreted. A handler provides the interpretation: it intercepts each operation and specifies how to resume the computation, possibly with modified state, redirected output, or transformed results.
This separation of operation from handler is the key structural advance. It means the same computation can be run with different handlers to produce different behaviors. A function that uses state can be executed with a handler that maintains a mutable reference, or with a handler that logs every state change, or with a handler that replays state from a recorded trace — all without modifying the function itself.
Handlers and Delimited Continuations
The handler mechanism relies on delimited continuations: when a computation invokes an effect operation, the handler receives not only the operation's arguments but also the remainder of the computation as a resumable function. The handler can choose to resume the computation (possibly multiple times, enabling non-determinism), abort it (enabling exceptions), or resume it with modified context (enabling state).
This is not merely an implementation technique. It is a structural property that connects algebraic effects to deep results in logic and category theory. The resumption of a delimited continuation is the operational counterpart of the cut rule in proof theory; the handler is the computational analogue of a logical elimination rule. Algebraic effects live at the intersection of programming languages, proof theory, and category theory — specifically, the theory of Lawvere theories and enriched category theory, where operations are morphisms and handlers are natural transformations.
The categorical semantics reveals why algebraic effects compose cleanly where monads do not. A monad is a monoid in the category of endofunctors; an algebraic theory is a presentation of a monad by operations and equations. The algebraic presentation is more structured than the monadic one, and this extra structure — the explicit operations and their equations — is exactly what makes composition tractable.
Effects in Practice: From Research to Languages
Algebraic effects have moved from theoretical curiosity to language feature. Eff, a language designed by Pretnar and Bauer, was the first to implement handlers directly. Koka, developed by Leijen at Microsoft Research, demonstrates that algebraic effects can be compiled efficiently to mainstream targets while preserving type safety. More recently, multicore OCaml added effect handlers as a core language feature, enabling direct-style concurrent programming without callbacks or monads.
The practical appeal is strongest in domains where control flow is complex and effectful: concurrent programming (where effects represent async/await without syntactic transformation), probabilistic programming (where effects represent sampling operations that can be intercepted for inference), and systems programming (where effects represent resource acquisition and failure modes that can be handled locally or propagated).
In each domain, the common pattern is the same: the programmer writes direct-style code that performs effects, and the handler provides the interpretation — concurrency, probabilistic inference, or resource management — as a separable concern. The computation is generic; the handler is specific.
The Systems-Theoretic Reading
Algebraic effects can be read as a systems abstraction as much as a programming language feature. A system with algebraic effects is a system whose behaviors are factored into a computational core (what the system does) and an interpretation layer (how the world responds). This is the same separation that appears in control theory, where a plant (the core) is designed independently of its controller (the handler), and in organizational design, where operational procedures (the core) are separated from policy decisions (the handler).
The handler is a feedback mechanism. It observes the system's requests (the effect operations), applies its own logic, and returns control to the system with modified parameters. The system does not know it is being controlled; it simply performs operations and receives results. This is the essence of feedback without coupling: the core remains agnostic about the handler, and the handler remains agnostic about the core's internal logic — except at the effect boundary.
This reading suggests that algebraic effects are not merely a convenience for programmers but a general principle of system design: separate the specification of what a system needs from the environment from the specification of how the environment provides it. The interface is the effect signature; the contract is the handler.
The claim that algebraic effects are "just" a programming language feature misses their structural generality. Monads were once dismissed as category-theoretic esoterica before becoming central to functional programming; algebraic effects are making the same journey, but their destination is larger. They are not a better way to write programs — they are a recognition that the boundary between a computation and its environment is itself a design choice, and that making this boundary explicit, typed, and interceptable is as important for systems that do not run on computers as it is for those that do. The handler is the universal adapter between intention and context.