If you're using them to pass around mutable state, yes. Which is why immutable/pure-functional is always the best first choice. If it's inconvenient to do som

If you're using them to pass around mutable state, yes. Which is why immutable/pure-functional is always the best first choice. If it's inconvenient to do something with pure functions, and you want to pass a bit of state around, you can use the State monad - it's 'simulated' mutable state, in that it's all pure functions under the hood, but it looks and feels like you're doing mutation. If it's too inefficient to simulate state via the State monad, you can use state threads (ST). This is more efficient in that it compiles down to real mutations, but it's safe in that you can't share your mutations until you've exited the ST. So it should force determinism. This is what you'd use for a fast, mutable, in-place sort. The above two solutions rule out having multiple writers, which is where STM (software transactional memory comes in). STM gives you atomic blocks which behave more or less like (in-memory) database transactions. I mainly use it for implementing workers and jobs and queues, etc. And if you actually just want to do anything then you use IO. It's more about being aware (in a compiler-checkable way) whether you're mutating or not than it is about outlawing mutation.