Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: Any FSM fans?

From: nitsch-lists:netcologne at: 6-Nov-2001 4:02

RE: [REBOL] Re: Any FSM fans? Hi Gregg, [greggirwin--mindspring--com] wrote:
> 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 ugh..
> 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 ..] uglity 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? -Volker