[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Moore-FSM on OpenWRT
- From: Justin Cormack <justin@...>
- Date: Sun, 2 Sep 2012 16:57:04 +0100
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