[REBOL] Re: Any FSM fans?
From: nitsch-lists:netcologne at: 6-Nov-2001 4:02
RE: [REBOL] Re: Any FSM fans?
> Hi Volker,
> << would it be possible to compile your dialect in Gabrieles objects, like
> vid compiles to faces? >>
> Yes. I just whipped up a little code generator for it, so it will generate
> the code in Gabriele's format. Generating objects directly shouldn't be a
> problem. It just means figuring out how we want to use these things so we
> know what to generate while minimizing redundancy. I.e. can I generate a
> single format that can be used for multiple purposes? If I write out
> formatted REBOL code, how do I make it easy to use the result with load,
> read, etc., whether in the same interpreter session, or loaded from disk?
yes, that was was made me wake again :-)
your dialect seems to express FSM's well,
while i usually read "this are the concepts" wow short
and here is a code-sample
> Something to keep in mind, and one of the reasons behind my design, is how
> REBOL creates objects. Since it clones them, you probably want to use that
> approach only when you have a small number of state machines (which will be
> the normal case). State Machine are now often being used to drive the AI in
> games. In those cases, you may have hundreds, or thousands of objects. In
> that scenario, you probably want to separate the state variable(s) from the
> state table they use.
seen in view-faces and protocolls:
instead of using functions in objects,
objects contain a special function-object like /feel or /handler.
because its an object, it is not copied by make,
so all faces or ports of a kind can share their functions
while seperating their data.
drawback is, on calls one has to pass the object as argument,
as you see in the various /feel-functions.
but with a dialect most of that [face/action face ..]
can be hidden.
in layouts for example the action is simply a block,
and vid makes [action: func[face..]arg-block] from it.
nice feature: if you change the feel or handler, you change the
behaviour of the object.
since with functions [open read close]
one can start with a handler accepting 'open
and throwing errors on everything else,
after open change handler forbidding open and
allowing [read close].
in a way this works like a little state-machine :-)
could this be helpfull with a larger amount of state-machines?