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

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-03 11:27:25

> 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.

And I'm getting the feeling that you haven't actually read the tutorial. 
Custom reactions aren't used in StopWatch and before they are introduced it 
is - I think - very clearly explained what they are good for: 
http://tinyurl.com/6hnod (right below the "A digital camera" title).

> 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. 

Sorry, I completely fail to understand what you mean here. Could you please 
rephrase?

[snip]
> 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.

I don't think so. Even the stuff in the tutorial needs to be based on some 
state model, otherwise people would ask me why example X behaves the way it 
does.

[snip]
> > 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.

And I'd say that such purely didactic examples tend to confuse people more 
than anything else. Sure, there always has to be some compromise in the 
intrest of brevity and clarity (Hello world & partly StopWatch), but in 
general I'd really like to show where the use of boost::fsm would make sense 
in *practice* (Camera).

[snip]
> 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.

Please let me know exactly which lines you consider pointless infrastructure. 
No matter what, I think most people figure out pretty quickly what is 
infrastructure and what not.

> > 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.

See my other answer.

> I guess this is what "deep history" is for, but

Probably not.

[snip]
> 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.

I can do that, no problem.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.