Monad Transformer Workshop

April 9, 2017

Azad Bolour believes that monad transformers are usually explained with insufficient motivation. He presents them in relation to ordinary function composition, using a novel perspective gained from participating in a monad transformer study group.

His talk has three parts:

  1. Motivation - why use transformers, how to derive them from first principles
  2. Implementation - getting into the specifics of MaybeT
  3. Usage - the way they play out in programs at large

This workshop includes a link to a repo of exercises. With this video and exercises you can get the full hands-on experience, and develop confidence using monad transformers for real-world Haskell.

Download Video: (HD / SD).

Exercises: github.


  • This talk assumes you know about monads but not monad transformers
  • Initially Azad had a problem getting enough motivation and background about what is going on with transformers
  • Why learn them?
    • If you’re going to be doing Haskell you’ll be using monads, but each one has only a single effect at a time
    • Monad transformers combine and propagate the effects of different monads
    • A lot of real-world haskell uses monad transformers, and we need to understand them in order to understand and troubleshoot those programs
    • If you’re going to create monads yourself, you can often make them more easily using transformers
    • When creating new monads you’ll want to create transformers to combine them with others
  • Generally a search for monad transformers on google leads to complicated stuff, and even the source code is hard
  • Example of using the Persistent library
  • An analogy with function composition
    • Let’s start with the notion of function composition. We’re familiar with (.)… how about (>=>)? It’s the closest monadic analog to composition.
    • This operator uses the same monad everywhere: (>=>) :: (a -> m b) -> (b -> m c) -> (a -> m c) but what about using different m’s?
    • We could call it hcompose, or heterogeneous compose. Azad calls functions a -> m b “monad producers” or “monad factories.”
    • Deriving what hcompose should be for various combinations of monads.
    • A source of confusion: monads (like Reader) are defined in the standard library in terms of transformers (like ReaderT). In its purist sense reader is just ((->) r), not ReaderT r Identity. The library uses a standard, but complex, infrastructure to define some of the monads.
  • Definition of Monads
  • Moving toward heterogeneous composition, starting at Kleisli composition
  • The crux is a heterogeneous join which flattens across two monads
  • Exposition in terms of fictitious “blenders”
  • Moving from blenders to transformers
  • lift vs return
  • lift via heterogeneous bind
  • MonadTrans has laws too (Azad prefers the Kleisli form of exposition)
    • Graphical representation of composition law


  • Reiteration of Azad’s shorthand notation
  • Example of lifting a list with MaybeT
  • Implementing MaybeT as a Functor (unbox - apply - box)
  • Graphical representation of nested fmap
  • (Not doing Applicative live)
  • A transformation trick for monads that are functions
  • Creating monads by applying transformers to the Identity monad
  • transformer packages


  • Stacking transformers
    • Nesting order reverses in the core
  • Example in this workshop comes from Monad Transformers Step by Step, a very instructive paper
  • Makes an evaluator for a simple language and continuously adds effects
  • Steps in building the evaluator transformer stack