Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-07 11:44:48

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