The pure lambda calculus is a world of values and functions with no side effects: nothing prints, nothing throws, nothing reads a mutable cell, nothing fails. Real programs do all of these things. The central puzzle of typed functional programming is how to keep the equational, referentially-transparent core — where e and its value are interchangeable everywhere — while still describing computations that print, fail, or thread state. The answer that reshaped the field is the monad: a single, astonishingly reusable interface that turns "a computation that may also do X" into an ordinary, first-class value.

A monad is not magic and not (originally) about I/O. It is an algebraic structure — lifted straight from category theory by Eugenio Moggi in 1989 to model effects in a denotational semantics, and then turned by Philip Wadler into a programming discipline. Once you see the shape, you find it everywhere: Maybe for failure, State for mutable stores, List for nondeterminism, Reader for an environment, IO for the outside world. All of them share the same two operations and obey the same three laws.

Moggi's idea: separate values from computations

Moggi's move is to distinguish a value of type A from a computation that produces an A while possibly doing some effect. He writes the type of such a computation as T\,A, where T is a type constructor capturing "the effect". A function that can fail is not A \to B but A \to T\,B — a Kleisli arrow. The whole trick is then: how do we compose two effectful steps A \to T\,B and B \to T\,C into one A \to T\,C?

Read m \mathbin{>\!\!>\!\!=} f as "do m, call its result x, then do f\,x." Sequencing — the thing imperative languages bake into the semicolon — becomes an ordinary higher-order function.

Kleisli composition, drawn

Bind lets us compose Kleisli arrows just like ordinary functions compose. Given f : A \to T\,B and g : B \to T\,C, their Kleisli composition f >\!=> g : A \to T\,C is \lambda a.\; f\,a \mathbin{>\!\!>\!\!=} g. The effects of f happen, then the effects of g, and the T wrapper carries the accumulated effect through untouched:

The top row is the "pure" world of plain values; each downward step wraps a result inside T. \mathsf{return} is the little arrow that drops a pure value into T for free, and >\!\!>\!\!= is the machine that unwraps the left computation, hands its value to the next arrow, and re-wraps the combined effect.

The three monad laws

An interface is only trustworthy if it obeys laws — otherwise refactoring changes behaviour. A monad must satisfy three equations, which say exactly that \mathsf{return} is a neutral step and that sequencing is associative:

In Kleisli-composition terms these are precisely "\mathsf{return} is the identity arrow, and >\!=> is associative" — the axioms of a category. That is the whole content of "a monad is a monoid in the category of endofunctors": an unhelpful slogan hiding a very helpful fact.

Two monads, one interface, running

Below, Maybe (failure) and State (a threaded integer store) are two utterly different effects — yet both are just a return and a bind. Once defined, the same sequencing code reads like straight-line imperative programming, but stays pure. Run it:

Notice the payoff: the plumbing of each effect — short-circuiting for Maybe, threading the store for State — is written once inside bind, and every program built on top is freed from writing it by hand. That is exactly what a language's do-notation (Haskell) or computation expressions (F#) desugar into.

Beyond monads: effect systems and algebraic effects

Monads have a well-known weakness: they don't compose. Combining State and Maybe and IO forces you to stack monad transformers, and the lifting boilerplate grows with the tower. Two research directions answer this:

• Effect systems annotate a function's type with the set of effects it may perform — a judgement \Gamma \vdash e : \tau \,!\, \varepsilon where \varepsilon is a row of effects (reads, writes, exceptions). The type checker then tracks and enforces purity where it matters.
• Algebraic effects and handlers (Plotkin & Pretnar) split an effect into operations (like get, raise) and a separately-installed handler that interprets them — much like resumable exceptions. They compose freely and are now in languages such as Koka, Eff, OCaml 5 and Unison.

Both keep Moggi's founding insight: an effect is data about a computation that the type system can see and reason about, not an invisible thing that happens behind the semantics' back.