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

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-18 02:12:40

on Sun Aug 17 2008, Darryl Green <darryl.green-AT-aanet.com.au> wrote:

> in this trivial FSM where much of the state is directly
> encoded in a couple of variables,

I don't know what the number of variables has to do with anything.  For
all practical purposes, unless you allow nested states or other esoteric
extensions to the traditional CS meaning of FSM, 16 bits is more than
enough to encode the state of arbitrarily complex state machines.

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

But Phil didn't encode the whole machine represented in the diagram.

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

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

I think so.  To start with, "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.

> or is there some unnecessary verbosity or lack of clarity in way that
> model is expressed in the language implemented by the library?

Well, that too.

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

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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com