4 ms·
You cannot implicitly read pacman.position as a subexpression like in C, because it is an effect, and the order of effects has to be explicit in Haskell. So it
by Peaker 10y ago
You cannot implicitly read pacman.position as a subexpression like in C, because it is an effect, and the order of effects has to be explicit in Haskell.
So it would have to look like:
pacman.position += speed
pos <- pacman.position
g <- ghostAt pos
pacman.lives .= g
Though a dead Pacman probably has no position, so it makes more sense that the last line is:
when g (pacman .= DeadPacman)
Messing up the order because of implicitness becomes much harder.
- jstimpfle 10y agoWhat 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.