Fri Mar 15 15:16:02 EDT 2013
Control rate combinators
Since hoistable expressions don't cover all cases, it's probably best
to split this into two parts: a state normalization / initialization
function, explicitly computed before the loop is executed, (and
possibly looping over a couple of states), and a loop function.
Trouble is: the state initialization function might produce constant
parameters that are not state parameters of the inner loop. How to
glue these together?
(s,i) -> (s,l) ;; Once
(s,i,l) -> (s,o) ;; Multiple times
This is actually not such a bad idea, since it also gives a way to
integrate block processing.
Let's let this ferment a bit more.
On the surface this isn't much more than a single state update, and a
way to push the `l' variables from setup block to loop block.
However, it does need to indicate to the caller where the final state
is stored, e.g. returning t&1. Otoh, a state init phase could be
mandated for all loops.
This should probably be defined at one place, i.e. ai-lambda-feedback.
Maybe a state post-roll should be defined also, for symmetry's sake.
This would allow some statistics to be gathered as outputs?
EDIT: So, we're there. A setup method exists and is pushed into
feedback/n. However, it is not clear yet how to use it. For
ai-array.rkt this needs to somehow capture all the bindings and push
them outside of the loop.
EDIT: There's a double assignment that shows up in the state setup
code. This can be split by defining 2 so structs.