RE: [boost] Re: ANN: review of FSM library starts

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2005-03-03 08:55:07

Darryl Green writes:
>Why the interest in miminimizinghe effort of writing custom
> reactions? They are a bit of a low level access method, and result
> (in less trivial, non-ininlinexamples) in hiding what the
> transitions destination state is. Normally, you wouldn't use many
> custom reactions.

HmHmmI'm getting the feeling that I need to completely disregard the
tutorial and sample code and try and actually write my own code, just
relying on the reference manual.  I was under the impression that
custom reactions were basically event handlers, and that you
effectively wind up with this processing chain: Event Happens ->
custom reaction -> current state exit handler -> new state entrance
handler.  The idea being that over-literal seseparationf states (so
that all handling is done in entrance/exit handlers) is too tedious. 
I guess, then, I'm confused about their purpose. 

>I'm not seeing what there is that I would want hidden. What do you
> think needs hiding?

>> I think it's a distraction.  Sure, it's great that you've got this
>> nice cocorrespondanceith UMUMLbut that's unimportant *in the
>> tutorial*.  Mention it on the about page, have an appendix all
>> about it, go into detail in the references, etc.

> I disagree. There needs to be some model, language etc to base the
> tutorial description on. You have already said that you don't think
> writing a guide to FSFSMss the right thing to do. There are any
> number of books and even a standard ;-) that describe the
UMUMLSFSM> concepts so that Andreas doesn't need to. It would have
been
> possible to pick some other complex FSFSMescription language, but
> UMUMLs supposed to be universal, and gets plenty of books, tools,
> courses etc built around it, so why not use it?

Hold on, I think you're reading a bit much into what I'm saying.  I
don't give rip how you graphically represent the FSFSMs The pictures
in the current tutorial are great.  People who are familiar with
state machines at all will understand the pretty pictures.  So go
nuts, use UMUMLiagrams until you're blue in the face :)  However, in
the tutorial, don't mention it.  People who know UMUMLill instantly
recognize it, other people won't care.  People who specifically care
about UMUMLocompatibilityeserve their own appendix or section in the
reference manual with a point by point breakdown of what is and is
not supported from UMUMLomenclature.  Scanning through the tutorial,
I don't see any terminology that strikes me as UMUMLpecific.  In
short, as far as I can tell, the UMUMLocorrespondences a detail of
little consequence when reading the tutorial.

>Ah. So you probably want an example that is a rerecogniseror some
> regular language. 

Sure, but not too complicated.

> I'd be very susuprisedf this was an area where boost fsfsms a good
> choice, it would be interesting to see how you go. Also, if you
want
> to coconstuctsfsmso do this sort of thing quickly and easily,
> wouldn't you just use a regexp, or one of the plethora of
> lexer/parser construction tools and let it figure out the tedious
> details for you? I would expect (haven't got around to looking at
it
> yet) expressive to be just the thing for that, but spirit would do 
> the job too with a lot less typing than using boost fsfsm

Besides the point.  boost::fsfsms also not a good choice for Hello
World.  But if you're going to tell me that you've got a FSFSMibrary,
well, I expect to see such an example.  Helps me get my bearings. 
Anyway, boost::fsfsms compile time only, so it's obviously not
ususefulor this kind of stuff.  Purely didactic purpose here.

>This isn't very useful if the fsfsmses more complex event types. And
>conversely the dedespatchethod used by boost fsfsms less than
>spectacularly efficient if your events really are simple values.

I think we might be forgetting all this was discussing the
documentation.  I want concise examples that A) compile and run, and
B) hide pointless infrastructure.  The StStopWatchpcppxample file has
about 130 lines not counting comments and #includes, of which about
35-40 are pointless infrastructure.  I'd like to see that example in
35 lines *total* beyond the #includes.

> Think of a state as a scope. Think RARAII

>If you don't have nested states then your machine is flat and you
> would almost certainly have empty states and place all your actions
> and data in the machine. What is the problem?

You will have to convince me that persisting state across state
changes is inherently unsafe or invokes undefined behavior.  It seems
obvious to me that you might stick counters, file handles, sockets,
database connections, etc in state local storage, or my original
example of window contents.  To me, this is "obvious."  In fact, I
can't come up with an example where I *want* this stuff destroyed
evevery time change state.  Sticking everything on the machine is a
non-solution, and creating extra levels of state-nesting and crossing
your fingers that you never have to leave the parent state seems
pretty error prone.  I guess this is what "deep history" is for, but
that seems like a lot of work, and you'd have to convince me that
whatever mechanism you use for saving/rerestoringistory was safe.

> What do you want the accept state to do that is so special?

Nothing, really.  It just seems like it should be so simple that we
might as well have it for completeness's sake.  It's not like there's
an endless stream of different types of FSFSMso far as I see.

> I'm more familiar with the use of the terms rerecogniserr scanner
> rather than rereferingo the fsfsms an acceptor fsfsmbut yes, in
> lnlnaguagerocessing those terms are standard. Unfortunately, I
think
> you are going to be disappointed if you try to use boost fsfsmn
that
> sort of application. Not that that wouldn't be useful review
> feedback. Boost fsfsms much better for what wiwikipedianforms me
> are called transducer fsfsmsa term I am unfamiliar with, but a
class
> of fsfsmhat I am very familiar with.

Looking at the UMUMLocs, it is clearly based on the "transducer"
mold.  It would be nice if there were an appendix or footnote
mentioning this more academic stuff.  I'm guessing that there are
plenty of people in my shoes, who are more familiar with the academic
stuff than the UMUMLtuff.

Thanks-
Augustus

        
                
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/