Re: [boost] [msm] Review
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?
5. MSM has eUML, which I have *not* used, to simplify the machine specification.
I'd also count it as an important interface difference. 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. 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). 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? 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. 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? How easy is your Statechart->MSM translator now? (Note: MSM->Statechart will stay pretty simple, right?) After seeing both versions, will we all agree that there are important interface differences and that these differences are an important distinguishing feature? Christophe
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
So you say: David Bergman writes:
On Dec 6, 2009, at 3:37 AM, Christophe Henry wrote:
<snip>
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.)
Then later follow that up with: David Bergman writes:
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.
Huh..? How is an EDSL (which I think constitutes a "wildly different interface" by most people's standards) that results in faster execution [1] not *exactly* analogous to the Regex vs. Xpressive comparison that you've brought up multiple times? Is it because eUML is optional, given Msm's support for multiple frontends? I can only point out that in addition to "static Xpressive" (the EDSL), Xpressive also contains "dynamic Xpressive," whose interface is extremely similar to Regex, probably intentionally so (indeed, I suspect this was lauded during Xpressive's review, not criticized). eUML makes up *~75%* of Msm's code and ~30% of Msm's documentation; metrically, it's obviously an extremely significant part of Msm, and is probably what warranted a major version increment between Msm versions 1.2 and 2.0. And yet despite not having used it, you've been very vocal about the supposed lack of differences between Msm's and StateChart's interfaces/representations. This seems to me misguided at best... I suspect that your contrast between Msm and StateChart has been tainted by your use of Msm's "standard" frontend. I could be way off here, but my impression from the Msm documentation is that the standard frontend exists mostly for backwards compatibility with 1.x code and to support older compilers, and that eUML is the recommended frontend for new FSMs on supported compilers. If so, I would suggest reexamining Msm from a fresh perspective, using eUML; now, given *that* interface and the very substantial implementation differences, would you still argue that Msm and StateChart are not different enough to warrant the inclusion of both into Boost? [1] http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/index.htm#_Performan...
On Dec 7, 2009, at 6:15 AM, Adam Merz wrote:
So you say:
David Bergman writes:
On Dec 6, 2009, at 3:37 AM, Christophe Henry wrote:
<snip>
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.)
Then later follow that up with:
David Bergman writes:
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.
Huh..?
How is an EDSL (which I think constitutes a "wildly different interface" by most people's standards) that results in faster execution [1] not *exactly* analogous to the Regex vs. Xpressive comparison that you've brought up multiple times?
It is clearly analogous. But I made it clear that I had not tried out eUML and referred to the non-eUML interface; you know, with mpl::vector of row's (vs Statechart mpl::list's) So, there should not be a need for that "huh" ;-)
Is it because eUML is optional, given Msm's support for multiple frontends? I can only point out that in addition to "static Xpressive" (the EDSL), Xpressive also contains "dynamic Xpressive," whose interface is extremely similar to Regex, probably intentionally so (indeed, I suspect this was lauded during Xpressive's review, not criticized).
eUML makes up *~75%* of Msm's code and ~30% of Msm's documentation; metrically, it's obviously an extremely significant part of Msm, and is probably what warranted a major version increment between Msm versions 1.2 and 2.0. And yet despite not having used it, you've been very vocal about the supposed lack of differences between Msm's and StateChart's interfaces/representations. This seems to me misguided at best...
I thought I was pretty clear about my arguments dealing with "MSM - eUML", both in clear statements that (i) I had not used eUML, but (ii) considered that to be a difference between the libraries, and (iii) that my examples contained the "regular" interface.
I suspect that your contrast between Msm and StateChart has been tainted by your use of Msm's "standard" frontend.
I have only looked at eUML briefly, but it is clearly the "Xpressive of FSMs". My comments pertained to "MSM - eUML" which I thought was clear from my arguments. When I first looked into MSM, it was an older version, and since that interface was still there in 2.0, I assumed that it was the "canonical" way of doing things in MSM (2.0.)
I could be way off here, but my impression from the Msm documentation is that the standard frontend exists mostly for backwards compatibility with 1.x code and to support older compilers, and that eUML is the recommended frontend for new FSMs on supported compilers.
That was not my impression. My impression was that the (old) standard interface was the canonical one, and eUML an "option" for developers.
If so, I would suggest reexamining Msm from a fresh perspective, using eUML; now, given *that* interface and the very substantial implementation differences, would you still argue that Msm and StateChart are not different enough to warrant the inclusion of both into Boost?
I would welcome eUML into Boost any day, from what I have seen (especially after playing with it this morning.) Do we really need a new underlying library for eUML, though? I am not sure of that. And even if we do (for now), and cherish the much faster execution speeds of MSM (in my non-complex but pretty big state machine examples), I would argue for an attempt at having eUML as an optional facade for both MSM and Statechart. /David
AMDG David Bergman wrote:
But I made it clear that I had not tried out eUML and referred to the non-eUML interface; you know, with mpl::vector of row's (vs Statechart mpl::list's)
I would expect both libraries to allow either mpl::vector or mpl::list. In Christ, Steven Watanabe
participants (4)
-
Adam Merz -
Christophe Henry -
David Bergman -
Steven Watanabe