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

From: Darryl Green (darryl.green_at_[hidden])
Date: 2008-08-17 23:00:04

On Sun, 2008-08-17 at 15:27 -0800, David Abrahams wrote:
> on Sun Aug 17 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
> 
> > David Abrahams wrote:
> >> on Sun Aug 17 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
> >> 
> >>> State machines, as I see it, are meant to define an object behavior,
> >>> IOW reduce the amount of undefined behavior. It is pointless to use
> >>> them to implement undefined behavior.
> >> 
> >> So std::vector is pointless because it exhibits undefined behavior when
> >> misused?
> >
> > No, vector is not pointless, because its purpose is to store elements,
> > not to define behavior. 
> 
> Sorry, but you're making no sense to me.  The defined behaviors of
> vector are just as important as the defined behaviors of your FSM
> library.
> 

Andrey appears to be saying that the whole concept of an FSM is built
around defining the behaviour in reaction to events, while the concept
of a vector is about storage and access to elements. His use of
"behaviour" was a bit loose/context dependent/needed an FSM to
interpret :-). Anyway, the OP (Phil) seems to believe that this
particular issue arose out of a bad choice of example than being what he
was trying to illustrate. That said, I'm still not clear on what exactly
that was.

> > I will need vector to store elements even with undefined behavior on
> > invalid pointers as its input. But why would I need FSM if it doesn't
> > define my object's behavior? 
> 
> Well, it would define useful behaviors for valid inputs.

Fair enough.

> 
> > Or if I am adamant on what particular input will come from the
> > environment (IOW, the behavior is already defined by the environment)?
> 
> The OP's assumption only works when you have sufficient control over the
> inputs.
> 

Right. However, in this trivial FSM where much of the state is directly
encoded in a couple of variables,there is no need to deal with invalid
inputs and the FSM has no deeper behaviour/actions; *any* FSM library
looks verbose. What we are comparing is DSELs, and, while you say that
it would be good to be able to embed the diagram, the diagram in the USB
example is an incredibly verbose representation (by count of nodes and
edges) of what is described by Phils code. Obviously you don't infer
from this that any attempt to embed state diagram (like) representations
in code is pointless, but you do seem to find the proposed libraries
representation less useful. Is it simply that the "states that handle
events" model is intrinsically not as clear as a diagram or transition
table, or is there some unnecessary verbosity or lack of clarity in way
that model is expressed in the language implemented by the library?

> >>> Please, have a look at my reply to Phil. I've attached a code snippet
> >>> with a transition map. Does that look more declarative?
> >> 
> >> Not really, to me.  It's very difficult for me to see the transitions in
> >> that code.  Compare that with either of my player examples.
> >
> > Hmm... I don't see much difference, except for comments markup. Both
> > code samples use transition maps, both use vectors... Is it because the
> > transition map in your code is a member of the complete FSM?
> 

There are 2 examples attached - the second with a transition map. I
rather like the fact that the library allows transitons to be defined by
a transition table as well as by defining event handlers/transitions
within each state.

> The STT in my code is clearly visible at
> http://svn.boost.org/trac/boost/browser/trunk/libs/mpl/example/fsm/player1.cpp#L226
> 
> Where's yours?
> 

I've pasted it here:

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;

Regards
Darryl