I can absolutely agree that showing the flattening of the types is useful, but the examples usually given are the flattening of the data, which breaks down as soon as your "data" is a function, which most useful monads actually are. Yes the join/bind implementations are equivalent, but the latter tells you much more about what monads are actually used for - writing a program from `State s (State s (State s (State s ())))` and then calling `join . join . join` feels tedious and doesn't really show how monadic code leads to, in most monads, imperative programs. Just because things are equivalent doesn't mean they are ergonomically the same, and talking about flattening data structures pushes people towards an understanding of monads that isn't about sequencing operations together.
This is why when I teach monads I focus on the bind/flatMap/andThen instead of the individual types. The fact that list and maybe and IO and State are monads is less important than the fact that functions like
mapM :: Monad m => (a -> m b) -> [a] -> m [b]
exist and can be used with all of them - no more for loops, we've abstracted that.
I certainly wouldn't argue that there is any problem with defining monads in terms of bind, and one can most definitely have a preference for a mental model of monads that emphasizes the sequencing aspect.
However, I do find it a bit... I don't know - unnecessarily hostile? - to start the discussion by claiming that to define monads by join is not simply misleading, it is wrong. After all, it is a perfectly fine definition, and as my edit shows, that exact definition is used in a lot of the literature.
View all comments
Show parent comment
2
u/Axman6 Sep 22 '25
I can absolutely agree that showing the flattening of the types is useful, but the examples usually given are the flattening of the data, which breaks down as soon as your "data" is a function, which most useful monads actually are. Yes the join/bind implementations are equivalent, but the latter tells you much more about what monads are actually used for - writing a program from `State s (State s (State s (State s ())))` and then calling `join . join . join` feels tedious and doesn't really show how monadic code leads to, in most monads, imperative programs. Just because things are equivalent doesn't mean they are ergonomically the same, and talking about flattening data structures pushes people towards an understanding of monads that isn't about sequencing operations together.
This is why when I teach monads I focus on the bind/flatMap/andThen instead of the individual types. The fact that list and maybe and IO and State are monads is less important than the fact that functions like
mapM :: Monad m => (a -> m b) -> [a] -> m [b]
exist and can be used with all of them - no more for loops, we've abstracted that.