State Monad for the Rest of Us

I don't see those as necessarily illegal states, but even so, it's not hard to handle by adding a third `Action` for it (I kept the example short and left the first `if` condition empty).

The second case, if there is an exception, it would be handled as such by simply switching the order of the `if` in the extension method. None of this seems confusing nor onerous in day-to-day use.

How so? Can't you just put your Tree in a Box?

    enum Tree {
        Leaf,
        Node(Box<Tree>, Box<Tree>),
    }

    fn number_of_leaves(tree: &Tree) -> u32 {
        match tree {
            Tree::Leaf => 1,
            Tree::Node(left, right) => number_of_leaves(left) + number_of_leaves(right),
        }
    }

    #[cfg(test)]
    mod tests {
        use super::*;

        #[test]
        fn counts_the_number_of_leaves_in_a_tree() {
            let tree_with_3_leaves = Tree::Node(
                Box::new(Tree::Leaf),
                Box::new(Tree::Node(
                    Box::new(Tree::Leaf),
                    Box::new(Tree::Leaf),
                )),
            );

            let leaves = number_of_leaves(&tree_with_3_leaves);

            assert_eq!(leaves, 3);
        }
    }

Happy to contribute even if in a minuscule way :-) FYI you changed the definition when it first appears, but not in the shaded box when you repeat it later in Chapter 1

Impure functions lack referential transparency, which is often sacrificed but kind of important to being a function - getting the same result every time you call it with the same input. Alternatively, you can say that every function has an implicit input parameter of the the current program state, but that turns every function on one bit of input to a potentially astronomically complex function of gigabytes of input.

I don't see why you think all monads are just like the State monad. The Maybe and Either monads have nothing to do with state, for example.

I think "context" is a bit more all-encompassing.

If I have an Int, then I just have an Int.

If I have an Identity Int, then I really still just have an Int.

If I have a [Int] then I have a list of Ints.

If I have a Maybe Int, then I either have an Int or I have Nothing.

If I have a Reader r Int, then I have a computation taking some input of type r and producing an Int. That computation can't modify the value of r.

If I have a State s Int, I have a computation taking some initial state of type s and producing an Int. The value of s may change during the computation.

All of these are monads, but calling all of them "state" is somewhat reductive.

The Haskell wiki tutorial on monads refers to them vaguely as "strategies" - I mostly agree with that description.

Monads can encode state but they don't have to.

I tend to think of a monad in computer science as something which is constructed from a type and a computation and wraps the return values of that computation in that type. That allows you to bake in "context" into that type which could be state in the conventional sense but it could be something else.

To make this practical, let's make a simple example of a simple somewhat useful monad with no state. Imagine you have all the regular trigonometric functions sine, cosine etc which accept radians[1] and you need versions which work in degrees. You could make a unit conversion monad which converts arguments on the way in and wraps the result in an inverse conversion monad such that if you passed it to arcsine arccosine etc on it it would know and return degrees on the way out.

Neither of those monads would have any state in the usual computer science sense, the main conversion is just multiplying all the inputs by pi/180 before calling the wrapped function and constructing a result monad type so the inverse trig functions do the opposite of that.

[1] ie the correct versions. Fight me physicists and engineers and you freaks who use gradians whoever you are[2].

[2] I think it's surveyors but I could be wrong.

Monads can be used to attach all sorts of things besides state to data. For example, you can associate read-only data, such as configuration, authenticated identies, etc. You can associate I/O methods, which can be real or mocked. You can have a place in which to scribble logs/traces (this feels like state). And yes, you can associate mutable state, of course.

The point of monads, from the point of view of programmer convenience, is that they let you have a bag of contextual stuff along with your values. Thus if you think of a server application that processes requests, you might want to carry all of:

  - configuration applicable to this request
    (or global configuration)
  - request metadata (time received, from where,
    from whom, authenticated how, etc.)
  - request processing state
  - logs/traces
  - I/O methods, so that
     - you can make all your code deterministic
       and thus easier to write tests for
     - so you can mock the world (see previous
       item)

Besides this there's everything about the Maybe ("Optional") and Error/Either monads that just makes it easy to make sure all errors and "nulls" are handled.

And what makes all of this possible (in Haskell) is the use of operators (functions) and syntax that lets one write "statements" that are actually combined into large expressions.

They are an abstraction of a sequence of operations, not the state used in those operations.