3 ms·
You missed the point where a program can take inputs over time. In your example, the program takes “step forward” and goes through the flows, eventually mutatin
by Rumudiez 5y ago
You missed the point where a program can take inputs over time. In your example, the program takes “step forward” and goes through the flows, eventually mutating state at the end, including redrawing the screen or prompting the user for their next input. The next input is based on the current state of the machine, and there can be as many or few valid state transitions as you, the programmer, would like to manage.
- Someone 5y agoWhat you propose requires some arrow leading (directly or indirectly) from mutate! to input. The model I commented on: input -> fn1 -> fn2 -> fnn -> mutate! doesn’t have such a loop.