Not only is that not cheating, it's actually completely reasonable in Haskell too! You can use ST to have as much mutable state as you like; the awesome thing i

Not only is that not cheating, it's actually completely reasonable in Haskell too! You can use ST to have as much mutable state as you like; the awesome thing is that the state is guaranteed not to leak--from the outside, the function is just as deterministic as one that doesn't use mutable references and data structures. The big idea about Haskell isn't to avoid all state. Not at all. The big idea is to control state. Haskell expects you to use state if it makes the logic clearer or the code much faster. What you do not do in Haskell is use state for program organization. You avoid global state as much as possible. This means that communication between disparate parts of your program are explicit--you don't have implicit dependencies everywhere. This is definitely a good thing. I think one of the problems is that people without much experience in Haskell interpreter "purely functional" too strictly. It just means you do not have state by default; you can still use it where it makes sense. The good thing about not having it by default is that it forces your program to be simpler and more decoupled and it lets the compiler and libraries make many more assumptions about your code. All sorts of awesome features like STM and data parallel Haskell depend on having this sort of control over side-effects. But that's all it is--control. You can still have state and side effects; however, unlike most other languages, you can also not have them.