However, to ensure I don't invoke the wrath of the math gods, I'd like to lay a few ground rules.
- This post is specifically about monads in relation to programming. The concept itself stems from category theory, but it has implications in the functional programming world.
- I'm not going to attempt to be accurate... just give a rough (and hopefully simple) view into this confusing subject.
- I'm not a math major... so my understanding is neither perfect or complete.
- I encourage you to study this topic in depth. There is a lot of value in understanding these concepts, especially as functional programming has re-entered the mainstream. :)
So, the thing that I see the majority of monad tutorials do is try to create an analogy. A monad is like {something} due to sharing {some property}. While these tutorials have definitely helped broaden my perspective on monads, I feel like it's important to point out that they are fundamentally wrong in one important regard.
A monad is not a thing, but rather a collection of properties of a thing.
This is critically important to understanding the concept of monads, as it is too easy to get bogged down in trying to memorize specific things that are monads and how they work. In my experience, it is often better to understand the fundamental properties of something. Armed with that understanding, the comprehension of the different expressions of that something becomes a lot easier.
However, before we can understand these monadic properties, we must first establish a foundation on which we can explain those properties. Thankfully, the basics of this foundation are, conceptually, quite easy to wrap ones head around.
In your programming language of choice, you likely have representations of the following two concepts...
Types like string, integer, array.
Functions like length, toString, split.
From category theory (a branch of mathematics that defines, among other things, monads), there is a term we can use to group types and functions. The term category defines a grouping of types, and functions that operate on them. Now, as you might have guessed, any random grouping of types and functions doesn't magically make a category. I won't go into all of the rules for categories (I don't know them all), but I think we can demonstrate some of the interesting properties of categories.
One category your programming language of choice is likely to have is related to lists. Remember that we said categories have two parts. Categories have types, and functions that operate on those types. What does that look like for list?
A category for list would contain all types of lists that you can possibly express in your programming language. Even if your language is dynamically typed, you can think of lists that are supposed to contain a certain kind of thing as a type of list. So, we could think of...
Lists of integers...
Lists of strings...
Lists of lists of...
That covers the first part of our category definition. Now let's think about functions that operate on lists. I should note that, one of those rules about categories is that the functions have to operate on a list, and also give you back a list. So, we can think about some functions that have that particular characteristic.
A function that, given a list of integers, gives you back a list of those integers squared.
A function that, given a list of strings, gives you back a list of integers representing the length of each string.
A function that, given a list of lists of ..., gives you back a flattened list.
Now that we know what a category is, we can talk about the monadic properties. Here's a rough sketch of our properties.
Property #1: There is a way to express a value from some category "x" to the category we're interested in.
Example of property #1 (scala):
Property #2: There is a way to translate functions from some category "x" to the category we're interested in.
Example of property #2 (scala):
Property #3: There is a way to translate functions that map between some category "x" and the category we're interested in, into a function that maps from the category we're interested in to itself.
Example of property #3 (scala):
There are our monadic properties. Now, as the examples demonstrate, lists demonstrate all of the monadic properties, however it is not the only thing in our programming language that demonstrates these properties.
As for the use of the monadic properties, there are several, but that's for another entry... :)
As for the use of the monadic properties, there are several, but that's for another entry... :)
