[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: function with program counter
- From: Philipp Kraus <philipp.kraus@...>
- Date: Sun, 15 Sep 2013 07:44:01 +0200
On 2013-09-15 00:56:32 +0000, Andrew Starks said:
We have a similar model, but use a function / filter graph, ala ltn12,
but not implemented that way.
Basically, you have a bunch of functions, but they're actually tables
with the __call method defined. You connect them with an "add_target"
method such that the return statement calls the next function or
functions (in the case of multiparented graphs, where one function
triggers multiple filters down the line).
You can store a "step" value in the argument list to the connected
function, if needed. This comes up for us when the graph is a tree of
When there is one source, or starting function, you can pump the
source: call the source function and trigger tail calls.
If it is a tree with multiple children per parent, then we tend to call
the final function (root / sink) and have it call its children,
processing their return values and then passing the output back. Since
all of the functions in the tree are doing the same thing, recursively,
the effect is that you get the output in the order that you expected.
Children that are not parents need sources, which might simply be
functions that pass back raw data when they are called, which makes
them look like plain filters to their parents.
Hopefully this is helpful. :)
you're also great. In combination with Tim's state machine idea this is
greate. I think I will use a metatable with a field for my program
counter and store the function into this table an can run all steps