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,
> fsm::transition_if<Address, SetAddress, Default,
> fsm::transition_if<Address, SetConfig, Configured,
> fsm::transition_if<Configured, SetConfig, Address,
> 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:
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 >,
> 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.
> 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
> 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk