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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-18 13:05:23

David Abrahams wrote:
> 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.

I'm sorry, I don't follow you. The question was not about how to encode
the state but about whether FSM concept is needed here. No matter, though.

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

So, you're saying that the library must be designed as Wikipedia says?
No less, no more? How discouraging.

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

The library supports both approaches for defining the FSM - the
state-based and the transition-based. I for one prefer state-based
approach and you, I assume, prefer transition-based. To my mind, it is
advantage that the library can be used both ways.

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

Sorry, I don't see why the code above is worse than this:

  struct transition_table : mpl::vector11<
      row < Stopped , play        , Playing , &p::start_playback  >,
      row < Stopped , open_close  , Open    , &p::open_drawer     >,
      row < Open    , open_close  , Empty   , &p::close_drawer    >,
      row < Empty   , open_close  , Open    , &p::open_drawer     >,
      row < Empty   , cd_detected , Stopped , &p::store_cd_info   >,
      row < Playing , stop        , Stopped , &p::stop_playback   >,
      row < Playing , pause       , Paused  , &p::pause_playback  >,
      row < Playing , open_close  , Open    , &p::stop_and_open   >,
      row < Paused  , play        , Playing , &p::resume_playback >,
      row < Paused  , stop        , Stopped , &p::stop_playback   >,
      row < Paused  , open_close  , Open    , &p::stop_and_open   >
  > {};

In fact, I find your syntax more verbose for the unneeded fourth column
of the table.