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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-19 14:11:14

David Abrahams wrote:

> Because the rows that don't begin with fsm::transition are opaque to me
> and don't appear to be symmetric with the other rows, whereas with one
> line of comments I can make my table completely transparent to anyone
> who knows what an FSM is:
> 
>         //   Start      Event         Next      Transition Action

As Darryl already noted, pure STT does not allow to describe
data-dependent transitions, which is a crucial feature. Aside from that,
my syntax is equivalent to yours.

As for data-dependent transitions, I've decided to allow users to put
their custom rules of transition. That makes each row in the table,
actually, a rule, which in trivial case always transit the FSM to the
target state. I could define another syntax, for example:

   typedef mpl::vector<
     fsm::transition<Attached, PowerOn, Powered>,
     fsm::transition_if<Default, SetAddress, Address,
                                              is_address_not_zero>,
     fsm::transition_if<Address, SetAddress, Default,
                                              is_address_zero>,
     fsm::transition_if<Address, SetConfig, Configured,
                                              is_config_not_zero>,
     fsm::transition_if<Configured, SetConfig, Address,
                                              is_config_zero>,
     fsm::transition<fsm::any_state, Reset, Default>,
     fsm::transition<fsm::any_state, PowerOff, Attached>
   >::type Transitions;

But it doesn't make it significantly better and, in fact, is more
limiting, because it doesn't allow to specify rules that apply to a
subset of states and events. A small example from the docs.

// Let's define the fsm::transition's analogue that triggers
// not only when the event type is equal to the specified,
// but even when it is derived from it.
template<
  typename CurrentStateT,
  typename EventT,
  typename TargetStateT
>
struct same_or_derived_event_transition :
  public fsm::basic_transition< TargetStateT >
{
  // We only need to specify the static predicate
  // that selects the transition
  template< typename StateT, typename EvtT >
  struct is_applicable :
    public mpl::and_<
      // We should check that state type is correct
      mpl::or_<
        is_same< CurrentStateT, fsm::any_state >,
        is_same< CurrentStateT, StateT >
      >,
      // Now we shall check the event type
      mpl::or_<
        is_same< EventT, EvtT >,
        is_base_and_derived< EventT, EvtT >
      >
    >
  {
  };
};

I feel that such flexibility is more important than syntactic sugar.

>> In fact, I find your syntax more verbose for the unneeded fourth column
>> of the table.
> 
> It's only unneeded if you think it doesn't convey information that's
> important to understanding the FSM.  From my POV, it does.  That's why
> arcs in an FSM diagram are often labeled with their associated
> transition actions.  How does a user of your library associate actions
> with transitions if they don't go in the table?

The action is totally defined by the event and the current state.
Handler names are always the same and thus need not to be present in the
table.