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:

Motivation - why use transformers, how to derive them from first principles Implementation - getting into the specifics of MaybeT 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.

Motivation

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

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



Implementation

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

Usage

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

Related Posts