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.