lua-users home
lua-l archive

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


On Sun, Sep 2, 2012 at 3:25 PM, Jan Lühr <lua@stephan.homeunix.net> wrote:
> Hello,
>
> Am 02.09.2012 um 16:20 schrieb Justin Cormack:
>
> On Sun, Sep 2, 2012 at 11:26 AM, Jan Lühr <lua@stephan.homeunix.net> wrote:
>
>
> FSMs are something that have a lot of personal style choices, and Lua
> is pretty flexible so any of them will work.
>
> First, I would define the guards as functions, not strings. Then at
> least you get to get syntax checking on them before runtime. So you
> will want to name all the states (eg counters) so you can refer to
> them in these.
>
>
> Personally I like to define everything in an fsm as a function, so
> each state is a function. Because Lua has proper tail recursion you
> can just call the next state (in Javascript you have to use a
> trampoline). Labels are fine too, but I find you can reuse state logic
> by using parameterized functions and other things like that. Also I
> like functions...
>
>
> Thanks for your hints - can you give me an example?

I would probably do something along these lines:

fsm = {
  start = "boot",

  counters = {count = 0},

  states = {
    boot = function()
      -- entry actions
      shell("blah")

      local nextstate

      -- tests
      local internet_avail = test_internet_avail()

      -- guards
      if internet_avail then nextstate = fsm.states.online else
nextstate = fsm.states.offline end

      if not nextstate then boot() end -- obviously not applicable here

      -- exit actions
      shell("blah blah")

      nextstate()
    end,


  },
}

It is not as object-y as your style, but the states are kind of too
simple that I would not make it completely table driven. But this is
very much a personal preference, and it does depend a lot on how the
code ends up, especially with external state transitions etc. Go for
readibility...

Justin