Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-06 12:23:31

On Dec 6, 2009, at 3:37 AM, Christophe Henry wrote:

> Hi David,
> 
> Thanks for bringing some depth to the discussion.
> 
>> 2. In Statechart, the definition of a state is coupled to the machine in which it resides
>> while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines
>> 3. In Statechart, the transitions are coupled to the from-state, and defined therein,
>> whereas in MSM, the transitions are coupled to the machine itself; this makes it a bit tricky to reuse a state in Statechart
> 
> This is an important interface difference, isn't it?

Yes, which is why I brought it up; see (*) below.

>> 5. MSM has eUML, which I have *not* used, to simplify the machine specification.
> 
> I'd also count it as an important interface difference.

I think it is, but have not tried it out (unfortunately.)

> You brought the following example, which will be a good starting
> point. Unfortunately, you seem to want to make it tell too much about
> Statechart/MSM similarities (I read "fairly similar") so let's tough
> it out a little.

* - Yes and no... As I explained in my note to Dave, I did not mean API when I wrote that dreaded sentence about the interface similarity, I meant it in a more abstract sense. BUT, for simple cases, where we do not deal with transition guards or nested machines, there actually is a quite close similarity even at a syntactical level.

> With Statechart, you had:
> 
> struct State1 : simple_state<State1, Machine> {
>  typedef transition<Event, State2, Machine, &Machine::action> reactions;
> };
> 
> And with MSM:
>  typedef mpl::vector<
>    a_row<State1, Event, State2, &Machine_::action>
>> transition_table;
> 
> 
> Now this example is a bit too simple to see a huge difference, so it
> is slightly misleading. If you don't mind, let's add a very simple
> thing, a guard (which is a boolean condition having the right to
> prevent the triggering of a transition).

They treat guards differently.

> With MSM this becomes:
>  typedef mpl::vector<
>    row<State1, Event, State2, &Machine_::action, &Machine_::some_condition>
>> transition_table;
> 
> Could you you maybe now show us how the Statechart version will look like?

You can not - AFAIK - have a guard in the transition table (or row) in Statechart; but I might be wrong.

> Let's now add a conflicting transition, which means another possible
> transition on the same event and the same source state, with guards
> deciding which (if any) transition will be taken.

We are now arguably leaving theoretical FSM's and entering pragmatic machines :-)

Again: for machines actually being FSMs, even the syntax is fairly similar, and the notions used (such as mpl::vector for the transition table in MSM and mpl::list for the transition row in Statechart) are often equal.

> With MSM you'd have, for example:
>  typedef mpl::vector<
>    row<State1, Event, State2, &Machine_::action, &Machine_::some_condition>,
>    row<State1, Event, State3, &Machine_::action,
> &Machine_::some_other_condition>
>> transition_table;
> 
> Could you now write the Statechart version for us?

No ;-)

> How easy is your Statechart->MSM translator now?

Not at all that simple. But, staying with actual FSM's, it is still simple.

> (Note:
> MSM->Statechart will stay pretty simple, right?)

This is a good point. In my limited experience with MSM, it does indeed seem to provide a superset of the features found in Statechart - modulo compiler limitations - and does so with fewer lexemes.

> After seeing both versions, will we all agree that there are important
> interface differences and that these differences are an important
> distinguishing feature?

Yes, there are syntactical differences and decouplings of state vs machine which makes MSM a nicer tool; and, didi I mention that MSM is in my simple test cases six times faster? But, the interfaces are similar enough not to have the audience go "holy crap" when seeing the other after the first.

But for "wildly different interfaces", I would except something along the lines of Regex vs Xpressive, not two tools using the same C++ constructs for virtually everything. For instance, if an FSM library used enums as states, it would be different. For another example of "wildly different interfaces" (in that they actually use different notions to solve the same problem), see DOM vs XPath-based API's.

/David