3 ms·
His example is amusing to me because state machines are one of my least favorite things to code in imperative languages (especially C). It's so easy to forget a
by joeyo 17y ago
His example is amusing to me because state machines are one of my least favorite things to code in imperative languages (especially C). It's so easy to forget an infrequently occurring state-interaction or side-effect. So if you want to be rigorous you end up with a meticulously detailed switch block (or whatever the idiom is in your language) with a lot of repeated code and global variables everywhere. My kingdom for a few closures!
- utx00 17y agocan you outline a sketch? closures by themselves do not guarantee the absence of side effects ie: (let ((state 'someobject)) (defun phase1 () (done1 state)) (defun phase2 () (done2 state) . . . and so on
- joeyo 17y agoSure; there's no silver bullet. My remark about closures was more to address his criticism that packaging up and passing around state was too much work to be worth it. Programming in Lua has a nice example of a maze game where state is passed around by emitting functions. It's a toy problem, but I think it's instructive: http://www.lua.org/pil/6.3.html http://www.lua.org/pil/6.3.html