Monads in Haskell: Confusion or Learning Opportunity?

Monad Confusion and the Blurry Line Between Data and Computation There's a common joke that the rite of passage for every Haskell programmer is to write a "monad tutorial" blog post once they think they finally understand with how they work. There are enough of those posts out there, though, so I don't intend for this to be yet another monad tutorial. This blurry line between data and computation, however, is not unique to monads. As I said earlier, we traditionally think about as a generic data type that represents either the presence of that data (with ), or the absence of that data (with ). In fact, it's exactly that blurry line that lies at the core of functional programming: first-class functions. We tend to think of these types as computations since they represent verbs like "performing input/output operations" or "computing a value while tracking state." As I thought more about this blurry line in Haskell between data and computation, it reminded me of a similar concept from the Lisp family of languages. We can implement monad for like this: This instance tells us how to string together two computations, and : If the first computation returns a value ( ), then the sequence returns the result of the next computation wrapped around that value ( ). (). Continue reading.