Re: [boost] [fsm review] Comparison with ad-hoc FSM coding

From: Darryl Green (darryl.green_at_[hidden])
Date: 2008-08-19 00:20:28

On Sun, 2008-08-17 at 22:12 -0800, David Abrahams wrote:
> on Sun Aug 17 2008, Darryl Green <darryl.green-AT-aanet.com.au> wrote:
> 
> > the diagram in the USB example is an
> > incredibly verbose representation (by count of nodes and edges) of
> > what is described by Phils code. 
> 
> But Phil didn't encode the whole machine represented in the diagram.
> 

No - but most of what he left out was checking for invalid inputs that
you have been claiming is not necessarily required. Adding in the
suspended state tracking in an ad-hoc way would only need:

bool suspended;

void bus_inactive() { suspended = true; }
void bus_activity() { suspended = false; }

A simple "flat" state diagram and a similarly simple state transition
table are always going to be very verbose.

> > Obviously you don't infer from this that any attempt to embed state
> > diagram (like) representations in code is pointless, 
> 
> I do think it's pointless in C++, although I don't do it by inference
> from anything you're mentioning.
> 

Wow! Does that mean you are against any FSM library or only one that
tries to represent a diagram by some method other than an attributed
edge list (state trainstion table)?

> "states handle events" is not part of the
> abstraction of what an FSM is.  Look it up in Wikipedia or any CS text.
> You won't see any such description.  Instead, that's a point-of-view
> unnecessarily imposed by the proposed library.  So the library's DSL
> isn't a faithful reflection of the ways we already talk about FSMs.

Ok - it is not the state that handles the event but the machine. I was
just trying for an abridged title for the model - not a formal
definition. That said I talk about FSMs in a lot of ways, often to
people who have never read a CS text in their lives. Some of the things
that they might have read include ITU Z.100 (SDL) which maps rather
nicely to Andrey's DSL (except for the lack of a way to send an event
back to the machine from within the event handler, something that Andrey
cosnders out of scope for the library).
 

> >
> > typedef mpl::vector<
> >   fsm::transition<Attached, fsm::event<PowerOn>, Powered>,
> >   SetAddressTrans<Default, std::not_equal_to, Address>,
> >   SetAddressTrans<Address, std::equal_to, Default>,
> >   SetConfigurationTrans<Address, std::not_equal_to, Configured>,
> >   SetConfigurationTrans<Configured, std::equal_to, Address>,
> >   fsm::transition<fsm::any_state, fsm::event<Reset>, Default>,
> >   fsm::transition<fsm::any_state, fsm::event<PowerOff>, Attached>
> >>::type Transitions;
> 
> The bits enclosed by fsm::transition look like they might be rows in an
> STT, although they're awfully verbose, with a great deal of surrounding
> syntactic noise that distracts from being able to read the actual
> semantics.  AFAICT, the other parts do not bear any obvious resemblance
> to rows in an STT.

I agree that the convenience classes that Andrey put together to
encapsulate the data dependend (gated) transitions are irregular. Can
you suggest a better approach to deal with them?