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

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-19 20:56:08

on Tue Aug 19 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> 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 

It is much more obvious what's going on from my POV.  But you could do a
lot with CRTP and smart naming choices to clean up the syntactic junk:

   typedef mpl::vector<
     row<Attached, PowerOn,      Powered                >,
     row<Default,    SetAddress, Address,    is_nonzero >,
     row<Address,    SetAddress, Default,    is_zero    >,
     row<Address,    SetConfig,  Configured, is_nonzero >,
     row<Configured, SetConfig,  Address,    is_zero    >,
     row<any_state,  Reset,      Default                >,
     row<any_state,  PowerOff    Attached               >,
   >::type Transitions;

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

Isn't the above "or" clause always true, and if not, why not?

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

If syntactic sugar didn't matter, we'd all be programming in assembly
language.  I believe it's possible to design an expressive DSL that
still has all the capabilities your library delivers.

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

I don't see how that answers my question.

> Handler names are always the same and thus need not to be present in the
> table.

Do you mean to say that every transition action is named the same and
the one to execute is chosen by overload resolution?

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