Monads As I Have Known Them

Are you really writing yet another Monad tutorial!?

No. This is not a Monad tutorial. If this were a Monad tutorial, I would need to be accurate and complete in my description of Monads. I, a repentant, often back-slidden, imperative programmer, have a tenuous, ephemeral grasp on what Monads are and what they’re good for. If you started from where I came from, just consider this blog post a breadcrumb dropped on the path to Monadic enlightenment…or the path to insanity. I’ll let you know when I get there.

What is a Monad, anyway?

For a complete, correct and nearly incomprehensible (to me, anyway) definition of a Monad, please consult Wikipedia. As far as I’m concerned, a Monad is principally a way to combine ‘monadic values’ with other ‘monadic values’, resulting in…other ‘monadic values’.

Ok, what’s a “monadic value”?

It’s the sort of thing that can be used with Monads. Ha ha, just playing! Well, I mean, that’s not wrong, but I can tell you some other things I’ve noticed about ‘monadic values’. Every monadic value I’ve come across has the following characteristics:

1. You can get some number of other values from it. Note that the number of values could well be zero.
2. You almost certainly have more than one monadic value with the same structure (i.e. the same way of getting values out of the monadic value).
3. There is a sensible way to combine or sequence monadic values together in a single expression such that result of that expression will be another monadic value (of the same type or structure).
4. There is a way to take an ordinary, non-monadic value and promote it or contain it as a monadic value.

What the heck are you talking about?

Good question. Let’s try to find an example of a ‘monadic value’. Consider point #1: I don’t know about you, but when I think of the sort of thing (value, object, whatever…) that I can get other things from, the first thing I think of is: Lists! And  considerning point #2, I don’t know about you, but my life as a programmer is filled with lots and lots of lists! And I get values out of lists the same way you do, one leg…I mean one element at a time. And point #3? Well, you’ve seen LINQ, right? And you’ve seen how you can combine two lists in a single LINQ query (with either a ‘join’ or multiple ‘from’ clauses)? Oh, you haven’t? Well, I know you’ve coded (or at least seen) nested ‘foreach’ loops and that, my friend, is combining two lists. Sure, it’s combining them in a dirty, shameful, imperative kind of way, but I’d expect no less of you. And finally, what about point #4? Well, if you can’t figure out how to take a value into a single-element list, I think you should reconsider your chosen profession.

So Monads are Lists?

Not so good with the logic, I see. Let us review: If all slicks are snicks and all snicks are pricks then…No! Monads are not (necessarily) lists! On the other hand there is a List Monad. But it’s not the only one! For example, in Haskell there’s also the Maybe Monad for combining values of the Maybe data type. If you’re a .NET programmer like me, you should know that the Maybe data type is quite similar to .NET “reference” types or Nullable<T>. In other words, it’s a container that can either contain null/nothing or a single value. The Maybe Monad combines Maybe values in such a way that if any of the combined values are null/nothing, then the overall expression is also null/nothing. What’s the value of the overall expression when all the values are not null/nothing? Well, that’s up to you, but whatever you come up with has to be a Maybe value.

There is also the State Monad for sequencing computations that have access to and can possibly mutate some shared state. In effect, this allows you to return to your sinful imperative ways when the need arises…without break the rules of functional purity! Miraculous! There is the Reader Monad, sequencing computations that have access to a (non-mutable) shared environment. And perhaps most famously, there is the IO Monad, which solves the ‘problem’ of representing IO in Haskell in a rather clever and elegant fashion.

This is hardly an exhaustive catalog of all the Monads there are. In fact, I’d guess there are many more that have yet to be invented!

Well, that’s nice, but I’ve gotten this far without Monads, so…

I know, and it’s very sad. Think of all the key-strokes wasted! Think of all the unnecessary heart-ache caused by errors in trivial “glue code”! You see, you can get along without Monads, but no one should have to live their life like that, writing the same code pattern over and over and over and…Monads are about writing that code once! And reusing it over and over and…Yes, I know, code re-use is what inheritance is for. But let me tell you something, in a programming language without functional-programming features, this level of code re-use is somewhere between very difficult and impossible.

Kind of makes you wonder if ‘objects’ are the right thing to build programs from, doesn’t it?