Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-06 13:31:17

Hi David,

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

Thanks for doing it, I see this as an important point.

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

Agreed. But isn't the interface similarity mainly due to the very
tightly specified problem domain and to the fact that we all use the
excellent MPL tool?
Of course, simple state machines using MPL will all look slightly the
same, as will do those based on OO-principles with each other.
When a new implementation (even based on the same tools) brings
important advantages, shouldn't it be considered for inclusion?

>They treat guards differently.

Yes. I'll come back to it in a minute.

>> 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 :-)

Sure. Theoretical FSM's are anyway about the same for all. My point is
to show that differences between MSM and Statechart are subtle but
play an important role.

>> 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 ;-)

Then, I'm not an expert with Statechart but allow me to try to help ;-)
I think (please correct me if I'm wrong) it'd look about like:
sc::result react(const Event& evt)
{
   if (some_other_condition(evt))
   {  action(evt); return transit<State3>();}
   else if (some_condition(evt)
   { action(evt); return transit<State2>();}
}

And this is one important difference, not just a syntactic one. With
SC, the structure of the state machine is hidden in the code, which
will make your conversion tool harder to write on the direction
SC->MSM as the tool will not just be able to parse the code but also
understand it. Add a few more actions or other piece of code and I
wish your tool luck ;-)
OTOH you get more flexibility.

So, my point is, there are more differences that syntactic ones, as
long as you make more complicated machines.
I still agree with you on the point that interfaces are not "widly
different" but I put this on the account of a clearly specified
problem domain and the fact that most of Boost uses the same MPL tool
(due its huge power. Thanks Dave, thanks Aleksey ;-) ).

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

You did and I thank you for adding your own tests to the review.

As an extra note, if you are ready to give up some state features and
need just an enum for the states, you might want to take the FSM in
the MPL book.
It would probably even be possible to make from it a backend which
could at some point partly support the different MSM front-ends.
MSM does not yet support this solution in order to deliver a back-end
supporting the state features specified by UML (again the restricted
problem domain) but it is one of the backends I consider for addition.

Do we agree to leave the dreaded sentence behind us and replace it
with one saying that both libraries solve the same problem using a
wildly different implementation with similarities in the syntax?

Christophe