I gave a talk at PyConAU – about monads. This blog posts contains some thoughts about the talk, and some addendum/errata that I was not able to cover in the talk. But first, here’s the talk and associated slides.

## Thoughts

Throughout the preparation for the talk I was exceedingly aware of the Monad Tutorial Fallacy, also commonly known as Crockford’s Law. Most examples out there use the null pointer exception (i.e functions that possibly return `None`

in Python), and my talk was going to do the same. It isn’t the most illustrative of what the power of monads are, but I ultimately chose that, and the list monad as examples, as it was ultimately the most beginner friendly (add to that I also actually actively use the maybe monad in my day-to-day work)

I tried to not use the wrap-in-a-context analogies (burritos, bucket brigades, space suits, boxes…) to explain monad, opting for a slightly more academic way of explaining them – via category theory. I’m not an expert in category theory, with only passing knowledge* Before learning about how category theory fits with programming, I had one prior experience with category theory years ago when trying to think up new puzzles after I got bored with Rubik’s Cubes – but those were the early days of Wikipedia and I didn’t learn much, but I think it did help me click together the concepts in the subject. I think my revamped visualizations of categories will raise the hackles of most mathematicians out there.

When preparing for the talk, I used a few things as a benchmark as to whether I did a good job explaining what monads are:

- If the audience realized that there are different kinds of monads, and that there needs to be some “glue” to help the different monads play nice with each other.
- If the audience understood that monads exist separately as a concept and as an implementation.
- If the audience understood them, they’d realize that I have skipped through some sections (the monad laws).

These three benchmarks allow me to gauge my audience’s understanding of things, and they would raise questions if they understood it. I think I succeeded on #2, but not #1 and #3, as most of the questions were actually related to that.

## Monad Transformers

On the topic of combining the different monads, I had actually prepared an example that combined the Maybe monad with the List monad in what Haskell users would call a `MaybeT`

. I wrote it in a mostly object oriented way, with each of the monads inheriting from the `Monad`

class.

Here’s the code. If you squint just right, you’ll note that the `MaybeT`

is itself a monad. In particular look at the parent `Monad`

object’s `bind`

method:

## The Missing Bits

In the talk, I skipped talking about the monad laws, but they were included in the appendix of the slides. Generally, the monad laws are pretty obvious and common-sense to someone who writes Python code, but in any case they weren’t the monad laws are written in pseudo-python that should be easy to understand. A monad needs to fulfill those three laws in order to be considered a monad.

I had hoped to also briefly cover what applicatives and functors were – and how many monads are also applicatives and/or functors – thus giving a broader overview of what monads are. I ended up not having enough time to do that.

## On `with context`

being Monadic

I fear that I hadn’t been too clear, in the talk as to what I meant when I said this code is monadic:

```
with open('blah.txt', 'r') as f:
lines = f.readlines()
```

If you think of monads as a collection of things (values and functions – specifically two functions called `bind()`

and `unit()`

), then what the `bind()`

function does is that it applies a function within a monadic value – making a function aware of the context that it’s performing its computations in.

Which is what exactly Python’s context manager syntax does. What I wanted to do was drive in the point that Python itself, provides solutions for things where you need to deal with values within a specific context. I had also hoped to drive in the point that monads, the concept, can exist distinctly from monads the implementation.

## Lastly

When preparing for the talk I read through many many monad tutorials. Eventually I got sick of reading the word monad, so I wrote a quick and dirty Chrome extension to replace the word “Monad” with “Gonad”. Yes it was childish. It is highly derivative of the Cloud to Butt extension. But it’s funny. In a childish way. If you want the extension, get it here. It’ll make this blog post a lot funnier. A LOT. I also just put the source into version control, and you can get it here.

If you have any nasty words about how I fucked up the idea of monads, or I’m not purely functional enough, please comment below.