← r/programming

r/programming·3 min read

Category Theory Explained for Haskell Programmers, Part 1 ZuriHac 2026

Master the categorical foundations that power Haskell’s abstractions and avoid subtle bugs by enforcing their laws.

The speaker starts by treating Haskell’s type system as a concrete category: each concrete type is an object and every pure function between types is a morphism. Composition is just function composition, and the identity morphism is the trivial id function. This mapping lets us reuse the whole categorical vocabulary without leaving the language.

A functor in category theory is a mapping between categories that preserves composition and identities. In Haskell that collapses to the Functor type class with fmap :: (a->b)->f a->f b. The two functor laws, fmap id = id and fmap (g . h) = fmap g . fmap h, become testable properties. The talk demonstrates these laws on Maybe, List, and a custom tree type, showing how a broken fmap immediately surfaces as a failing QuickCheck property.

Natural transformations are polymorphic functions of type forall a. f a -> g a that commute with the action of any morphism. The presenter uses the classic example of converting Maybe to List: maybeToList :: Maybe a -> [a]. By checking that maybeToList . fmap h = fmap h . maybeToList for arbitrary h, the audience sees how parametricity guarantees the naturality condition without extra boilerplate.

Monads are presented as monoids in the category of endofunctors. The three components, return, (>>=), and the monad laws, are derived from the associativity and identity of the monoid operation (bind) and the unit (return). The talk walks through the Writer monad to illustrate how the underlying monoid (a string or sum) drives the effect, and how violating associativity leads to observable ordering bugs.

Finally, the speaker argues that understanding these categorical underpinnings lets Haskell engineers reason about code reuse, refactoring, and library design at a higher level. By treating type classes as categorical structures, one can predict how new abstractions will compose, and catch subtle violations early with property‑based testing.

TakeawayEnforce the functor identity and composition laws; any fmap that violates them is a bug.

Prodigy briefing — continue on the original for source material, discussion, and updates.

Read original ↗