Yes, you can implement an "error monad" instance for each of a given set of procedures (returning Either, Maybe, or whatever). You can also wrap each of a give

Yes, you can implement an "error monad" instance for each of a given set of procedures (returning Either, Maybe, or whatever). You can also wrap each of a given set of procedures that don't conform to a uniform interface (say, return null or < 0 on error) to be conformant. That's just basic hygiene. I don't see a problem. > Monads abstract and generalize the concept of chaining computations. I get that, but in the real world I don't find any need beyond sequencing (first do this, then do that) and the occasional nested-for or early return. Everything else is only giving up on other things that are extremely important, like modularity (complex types / protocols are inherently anti-modular) and deterministic resource usage. > This is why every single monad code example in the article is identical. I didn't even notice that, and I do not consider this a desirable goal at all. The examples do totally different things, and you want to see that. There's no need to swap one out for the other in any realistic scenario. Ever.