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