Thanks. Very interesting! I agree monads can be understood in multiple ways. But so can side-effects -- as you point out yourself ("designers had to make some

Thanks. Very interesting! I agree monads can be understood in multiple ways. But so can side-effects -- as you point out yourself ("designers had to make some choices as to what is considered a side effect"). Why should Haskell's definition of side-effect be the be-all-and-end-all of analysis on what counts as an effect? I do think that Haskell's choice of what counts as an effect is wrong, both from a theoretical POV and pragmatically. I'm happy to defend this claim, but HN is probably not the right venue for this. (Just two hints: (α) if you think about types from the POV of guaranteeing linearity by types, then non-termination is clearly an effect, and not one that should be IO; (β) Scala's approach to monads doesn't guarantee effect freedom, yet is widely used.) I consider the (co-)monad abstraction to be orthogonal to effect definitions, with the purpose of (co-)monads being to allow abstracting out certain boilerplate do to with composition.