3 ms·
What you say (re: subexpression) is true in Haskell. (I was of the impression that "pacman.position" wasn't valid Haskell anyway, but now I think it is. Never h
by jstimpfle 10y ago
What you say (re: subexpression) is true in Haskell. (I was of the impression that "pacman.position" wasn't valid Haskell anyway, but now I think it is. Never had a serious interest in lenses).
However that's a cosmetic issue. The point still stands: If you chain ("use the State monad"), the outcome depends on whether you update the position or the liveness first.
- Peaker 10y agoIt 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.
- jstimpfle 10y agoYes, that was actually my point. State is essentially function composition. Thus I'm arguing for avoiding dependencies between conceptually independently compositions.
- Peaker 10y agoIt'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.