lua-users home
lua-l archive

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


Was going to suggest the "hsm_statechart" library which I found on luarocks site, and thought to be a way to implement state-machines in lua (ala iMatix Libero, not sure if anyone here used it). However, came across this reply, which seems very interesting. Any chance of being able to post some small sample that explains the method to the uninitiated -- time permitting ?


On Sun, Sep 15, 2013 at 6:26 AM, Andrew Starks <andrew.starks@trms.com> wrote:


On Saturday, September 14, 2013, Philipp Kraus wrote:
Hello,

I would like to use a list structure for calling Lua function. So some explanation.
I have got a function e.g.

function test({…})
     do first call
     do some print
     do second call
     do some print again
     if (a)
        do A
     else
        do B
     end
     ….
end

I have got also a "program counter" which is started by 1. On 1 its should run "do first call" on 2 "do some print" and so on.
I would like to use a Lua function, but I would like to run this function step-by-step. I can use a if construct to check the current
"program counter value" and run the correct command, but this is not very nice.

Did you have an idea for this problem?

Thanks

Phil

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

-Andrew