3 ms·
> In some ways, the goto program is easier to understand. Why? Because: > 1. The variables of the graph are all declared together in one place. [...] > 2. Typ
by afiori 3y ago
> In some ways, the goto program is easier to understand. Why? Because:
> 1. The variables of the graph are all declared together in one place. [...]
> 2. Typically, functional languages, like C, do not have named parameters. [...]
I have little experience in C, but probably I would try to use a struct for the machine state.
Even with no tail calls I think I would try to write the machine as mostly block of
bar:
step_bar(&state);
goto foo;
From my optic the benefit of tail calls is the ability to mix flow control and machine steps with function abstractions.
- kazinator 3y agoYes; or well: void step_bar(state *state) { state.x = state.s + 1 return step_foo(state) } This is where the single dispatch OOP with implicit class-scoped "self" reduces noise: void state::step_bar() { x = s + 1; return step_foo(); } You have the tail calls, all variables in one place: x is always the same x. You know which variables are being set in each state transition; no need to look through parameter positions in function definitions.