done with the closure machine idea

register_flow_routine.md

@@ -1,3 +1,7 @@
 # Register Flow
 
-In the loop discussion in base_instructions, one consideration was consuming a set of registers in data-order, mapping those with combinational logic suited to a stack machine, then updating those registers as appropriate. It might be possible to design a whole processor around this concept. It would allow the use of registers, which would only really need to be written to (reading happens automatically), without any signifcant overhead. This is incredibly powerful for loops, but it could also be used for routines which need to be called several times which update some common state. In a loop, the state is shared across all loop iterations. However, state might also be shared across all invocations of a function on a particular datastructure. This "solves" the issue of data ordering, with the exception that the data always needs to exist in the correct order, which might not be the case for all methods/branching paths. This then becomes a problem of data currying, to reorganize a structure's data into processing order for any given operation. This means that if we have a closure which only has one execution entry point, it will require no currying. Therefore, it might be preferable to try and reduce problems into functional coding problems using closures where all state is associated with a closure that automatically loads all relevant state into the processing order on invokation. Such a machine could be called a **closure machine**, since all invocations close over data that is loaded into a stack to be processed and leave the return arguments on the stack.
+In the loop discussion in base_instructions, one consideration was consuming a set of registers in processing-order, mapping those with combinational logic suited to a stack machine, then updating those registers as appropriate. It might be possible to design a whole processor around this concept. It would allow the use of registers, which would only really need to be written to (reading happens automatically), without any signifcant overhead. This is incredibly powerful for loops, but it could also be used for routines which need to be called several times which update some common state. In a loop, the state is shared across all loop iterations. However, state might also be shared across all invocations of a function on a particular datastructure. This "solves" the issue of data ordering, with the exception that the data always needs to exist in the correct order, which might not be the case for all methods/branching paths. This then becomes a problem of data currying, to reorganize a structure's data into processing order for any given operation. This means that if we have a closure which only has one execution entry point, it will require no currying. Therefore, it might be preferable to try and reduce problems into functional coding problems using closures where all state is associated with a closure that automatically loads all relevant state into the processing order on invocation. Such a machine could be called a **closure machine**, since all invocations close over data that is loaded into a stack to be processed and leave the return arguments on the stack.
+
+## Closure machine
+
+After investigating the idea, most paradigms are not applicable to the closure machine and it is better applied to the loop. Loops are the places where repeated loading of processing-order data is required.