Just a follow up on my last post, I've put up the code for parsing lua statecharts ( aka. hula, which stands for... ummm... let me make something up off the cuff: the "hsm-statechart under lua api" ), and a unit test (which is the only sample code for the lua bits right now).

A quick postmortem:
I completely forgot that Lua's C interface is stack based. I get why the interpreter works that way, and I even get why you'd want to expose that interface to C, but I remember being mystified why it doesn't also expose an object model  -- ( like python does ) -- and I still am. Even if the interface only existed for tables, it would significantly shrink the C code necessary to use Lua. If you could somehow just store a pointer to the table object, not table index + L state, it would be even better.

At any rate, stack manipulation added a lot of subtlety missing from the pseudo code. It's complicated enough, in fact, it would have been easier to expose the builder interface to Lua, and have Lua do the parsing of its own tables. ( I think this is a general pattern of Lua: it's *much* easier for Lua to script C, then it is for C to manage Lua. Ideally, there'd be a more equal footing. )

The biggest thing I missed, however, were the changes necessary to the hsmBuilder interface.  hsmBuilder had only supported guards and actions, but to allow lua functions to fully process an event.
  state_name = {
     event_name = 
          if ( then
            return 's21'
In the above example, the lua function wraps up the concept of a guard "", the concept of an action "",and the concept of a transition "return s21", all into one.

Since builder had kept stages separate, now there is a new top level stage -- a nice tree of processing -- that says "process event for state", and generically calls to either a user defined function ( in this case a hula defined function that knows how to run the lua code ), or to the step-by-step guard, action, transition handler it had previously.

I'm probably going to take a break from statecharts for a bit to get back to working on my ios game, but i'm going to try to sneak in some time to expose the builder and statemachine interfaces into lua for easier use.


ionous said...

Here's an example of what i mean: cloning a table in lua. Obviously, i'm not the only one who wishes there was an object model of some sort.

And, just to be clear, i at least, am not talking about a C++ wrapper for lua, just a pure C interface that lets me say: lua_isnil( table_object, key );

instead of things like: lua_pushvalue( L, key ); lua_gettable( L, table_index ); lua_isnil( L, -1 );