It does, but unlike impure languages, this ordering is not implicit in the evaluation order -- but explicit.
In the same sense, if you compose the pure functions:
updatePacmanPosition . checkPacmanAlive
vs:
checkPacmanAlive . updatePacmanPosition
Will exhibit the exact same issues.
The state monad merely lets you more conveniently write it more like:
do
updatePacmanPosition
checkPacmanAlive
Where the do stmts are (sort-of) composed together as functions.
So the state monad here is not the issue -- it is sugar around function composition.
The issue is whether the ordering of these manipulations is explicit via data-flow or statement ordering, or whether it is implicit in evaluation order applying to shared, mutable state.
Yes, that was actually my point. State is essentially function composition. Thus I'm arguing for avoiding dependencies between conceptually independently compositions.
It's true until the composition and data flow are hidden from view because they're implicit in the shared mutable state. Also aliasing issues don't occur with the composition as they may occur in mutable state.
In the same sense, if you compose the pure functions:
vs: Will exhibit the exact same issues.The state monad merely lets you more conveniently write it more like:
Where the do stmts are (sort-of) composed together as functions.So the state monad here is not the issue -- it is sugar around function composition.
The issue is whether the ordering of these manipulations is explicit via data-flow or statement ordering, or whether it is implicit in evaluation order applying to shared, mutable state.