I will corroborate that as a partial explanation. And it should remind you of SSA form, since it helps accomplish similar things. I think that’s a confusing place to start though, because people tend to ask why functional languages don’t just run things in a certain order anyway. And they do, take printNum( readNum() + 1 ), this will clearly read a number before trying to print the number.

Instead, assume we have a VM that only understands simple “math style” functions like:

f(x) = expression

Such as:

square(x) = x * x

So yes we could write:

main() = printNum( readNum() + 1 )

But we could not write:

main() = print("multiple"); print("expressions"); print("in a sequence")

That is, the VM does not implement multiple statements in a function, it expects only a single expression. Why not? Ignore that for now. This code will work though:

main() = printStage1()
printStage1() = printStage2(print("multiple"))
printStage2(x) = printStage3(print("expressions"))
printStage3(x) = print("in a sequence")

See how that would work?

That’s tedious as hell to write though. Humor me, and now lets write it with lambda expressions. Lambda expressions are function values, i.e. these two definitions of main are equivalent:

main() = print("hello world")
main = λ() -> print("hello world")

Notice I’m using main() = to define a named function, but just main = with lambda. This is exactly identical to the following javascript:

function main() { print("hello world"); }
main = function() { print("hello world"); }

So we can rewrite our program like so:

main = printStage1
printStage1 = λ() -> printStage2(print("multiple"))
printStage2 = λ(_) -> printStage3(print("expressions"))
printStage3 = λ(_) -> print("in a sequence")

Now lets inline some things, one step at a time:

main = λ() -> printStage2(print("multiple"))
printStage2 = λ(_) -> printStage3(print("expressions"))
printStage3 = λ(_) -> print("in a sequence")

main = λ() ->
         (
           λ(_) -> printStage3(print("expressions"))
         )( print("multiple") )
printStage3 = λ(_) -> print("in a sequence")

main = λ() ->
         (
           λ(_) ->
             (
               λ(_) -> print("in a sequence")
             )( print("expressions") )
         )( print("multiple") )

We now have a strategy for compiling a sequence of expressions into a single lambda expression, that returns the result of the last expression. Notice that I used underscores for the lambda args, because their result was unused by the function. But what if our program uses variable names? These are equivalent:

main() = {
  n = readNum();
  printNum(n);
}

main = λ() ->
         (
           λ(n) -> printNum(n)
         )( readNum() )

Hopefully you can now see that we could write a compiler that converts normal imperative code with variable assignments and so on into an unreadable chain of simple lambdas.

So why would you want to do that? Well, if this was a language we were implementing, we can add imperative syntax to our language without actually extending the VM. Our language interpreter can pre-process the code into simple lambdas, then the VM only has to know how to execute simple lambdas. That’s neat.

It also lets us make radical simplifying assumptions, just like SSA. Function calls can be evaluated in any order, as long as all its arguments have been evaluated first, just like SSA. But the way we’ve done it so far makes every line dependent on every previous line. So now lets split = into = and <-, where = denotes a weakly ordered assignment, and <- denotes a strongly ordered assignment.

main() = {
  a = 7
  b = 2
  x <- readNum()
  y <- readNum()
  _ <- printNum(a / x + b / y)
}

We don’t actually need to create a new lambda until we hit a strong assignment. So this simple lambda code is equivalent:

main = λ() ->
         (
           λ(a, b, x) ->
             (
               λ(y) -> printNum(a / x + b / y)
             )( readNum() )
         )( 1, 2, readNum() )

Okay but what if we screwed up and wrote this:

main() = {
  a = 7
  b = 2
  x = readNum()
  y = readNum()
  printNum(a / x + b / y)
}

Which would compile to this:

main = λ() ->
         (
           λ(a, b, x, y) -> printNum(a / x + b / y)
         )( 1, 2, readNum(), readNum() )

If functions can be evaluated in any order, will x or y be read first? It’s undefined. Either readNum() call could run first. You shouldn’t be allowed to weakly order things like IO. That should be an error. One way to do that is to give readNum a type, that insists its return value must be strongly assigned. But readNum should also be ordered with respect to printNum, and anything else that does IO.

So lets define these functions with a special return type that says they are both IO:

readNum(): IO(Number)
printNum(n: Number): IO()

This IO wrapper type must be strongly assigned, and the result of its assignment will be its inner type. That is, these are basically equivalent:

x: Number = 1
x: Number <- IO(1)

That’s the IO monad.

The strong assignment operator <- is called bind. A monad’s bind function takes a function, and returns a new monad, that represents the result of applying the function to the monad’s inner value. Using our typed readNum and printNum, our program looks like this:

main() = {
  a = 7
  b = 2
  readNum().bind(
    λ(x) -> readNum().bind(
      λ(y) -> printNum(a / x + b / y)))()
}

If you’ve ever written node.js before, you might be thinking hey wait a minute, that’s just an IO callback! Honestly yeah, pretty much. But with strong typing and syntax sugar. We can write this:

x <- readNum()
y <- readNum()
printNum(x + y)

But if we write this, it’s a type error:

x = readNum()
y = readNum()
printNum(x + y)

Why? Because the + operator has the type signature Number + Number, not IO(Number) + IO(Number). Even if + was defined for IO(Number), printNum still takes a Number, not an IO(Number). The type system forces us to bind properly.

So now our VM (or compiler) can treat all assignments as weak, because we’ve implemented strong assignments on top of weak assignments and lambdas. Normally assuming all assignments are weak by default would make the language hugely error-prone to use. But the IO functions all return an IO monad, so the type system protects us. Constrast with a conventional imperative language, that must assume all assignments are strong unless it can prove otherwise.

Naturally the weak assignment strategy opens up a lot more opportunities for certain kinds of optimization. Haskell still hasn’t taken over the world though, cause there are a lot of other opportunities for optimization, like hand writing vectorized assembly. That kind of thing is harder to do in Haskell than e.g. C.

That’s one of the ways Haskell uses monads, but IIRC (and I probably don’t RC), that’s driven more by Haskell’s lazy evaluation than a fundamental property of functional languages.

A more general use case of monads is the Maybe monad, which lets you control for nulls. If a function could return an integer or a null, you instead say its return value is Maybe Int. Then the type system can enforce that anything that calls that function handles both the integer case and the “null” case.

I do keep reading these monad things and getting confused about it.

Monads are mathematical structures. They have nothing to do with computer programming whatsoever. In fact, monads are so ridiculously general compared to most other mathematical objects that there is no way they could serve a concrete purpose for non-mathematician standards. So the first thing monads are not is “something you use”.

Theoretical computer scientists (read: mathematicians) discovered [0] that you can “give a semantics” to a higher-order [1] strict [2] language in which “types” are denoted by “objects in a category C”, and “a computation that produces a value of type B from a value of type A” is denoted by “an arrow A -> TB”, where T is “a strong monad over C”. The tl;dr of all this [3] is that monads are “something intrinsic to the very structure of the programming languages we use”, just like the Earth’s gravitational field is “something intrinsic to the very structure of the world we live in”. You don’t need a mathematical model for it to exist, although it is nice to have one for some purposes.

However, Haskell is a lazy language, so it is intrinsically comonadic rather than monadic. (Again, [3].) And, while Haskellers like their lazy language overall, they also want the sequential structure of their effects to be more like what strict languages have, because lazy effectful computations are insanely hard to reason about. So you could say Haskellers have monads in their standard library because they don’t have it in their core language.

I have made essentially the same point elsewhere.

Footnotes:

[0] As opposed to “created”, like operating systems, word processors or computer games are.

[1] Having procedures as first-class values, e.g., Lisp, Python, Java, ML, Haskell.

[2] Reducing arguments to a normal form before they are passed to a function, e.g., Lisp, Python, Java, ML, but not Haskell.

[3] Lots of details omitted. It doesn’t really matter what any of this means anyway.

I waited a whole day before posting it!

I’m not sure what you mean. I do, in fact, support making material available in multiple formats. It’s a best practice for accessibility, in fact.