lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 some variety. 

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. :)

Hi Andrew,

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