> For all practical purposes it is used to write code that exerts (local) side effects into the state maintained by the state monad. Yes, but as long as this i

> For all practical purposes it is used to write code that exerts (local) side effects into the state maintained by the state monad. Yes, but as long as this is done with only pure expressions, then the whole program is pure functional - that is what the definition is about. > You can a function in say, OCaml, that fills an array via mutation using only function arguments to deduct the contents, and then returns that array. That function is pure (it exerts no side effects outside and is not exposed to side effects from the outside, its result value only depends on the function argument values). Yet how is that not using mutation, non-referentially transparent parts inside? The guarantee or at least convention of referential transparency for every expression has benefits. It means I as a developer can make certain assumptions about code that I could not make otherwise. I can do certain refactorings and changes while being sure that it will not change the program semantics. As soon as parts of the program is not pure anymore, I know have to always re-assure myself that I'm currently working with the pure part of the code. Same for any tooling that I build. As I said, you can make that choice and sometimes it is the best thing to do - but you cannot call your application "pure functional" anymore when you do.