Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-12-03 22:19:37

On Thu, Dec 3, 2009 at 7:54 PM, David Bergman
<David.Bergman_at_[hidden]> wrote:
> On Dec 3, 2009, at 9:22 PM, OvermindDL1 wrote:
>
>> On Thu, Dec 3, 2009 at 6:18 PM, David Bergman
>> <David.Bergman_at_[hidden]> wrote:
>>> On Dec 3, 2009, at 6:27 PM, Andreas Huber wrote:
>>>
>>>>> We do not have this much overlap in any other library w.r.t.
>>>>> features and interface.
>>>>
>>>> What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
>>>
>>> Actually, I meant to include the triplet Regex, Spirit and Xpressive in my discussion about the closest case to the Statechart/MSM situation.
>>>
>>> Since Xpressive - conceptually - solves the problems of both Regex and Spirit, one could argue that it would be the only one needed in this triplet. BUT, the interface to regular expressions (and regular languages) is quite different between Xpressive and Regex and the latter conforms more to the Perl+GNU-style API's of dealing with regular expressions.
>>>
>>> If I were king of the world (...), I would standardize on Xpressive and deprecate both Spirit and Regex, *with regards to* interface and features (and not implementation.) Regex is obviously easier to wrap around a proven and efficient implementation such as PCRE, and is easier to inject in C++0x...
>>>
>>> It is no coincidence that Xpressive came after Spirit and Regex.
>>>
>>> In fact, I have had to explain - and justify - this triplet to new Boosters in my teams. But, we here have different interfaces and different problems (or languages to parse): regular vs context-free vs both. For less DSLish developers, Regex is the clear choice for regular expressions. But, I have managed to convert a few people to become DSL:ers, and am planning to open their eyes to Proto; once they get hooked on DSL, they love Spirit and Xpressive.
>>
>> Actually Spirit and Xpressive have different domains. Â Xpressive is a
>> regex parser, suited for regex stuff, *not* suited for parsing a
>> language. Â Spirit is a PEG parser, suited for parsing complex things,
>> not always suited for regex stuff, they actually have little overlap.
>
> Yeah, I was exaggerating the commonalities a bit (between Xpressive and Spirit) - although it is possible to create parsers for toy languages in Xpressive. I did that partly to question the validity of my own point: that the MSM/Statechart overlap is a unique situation for Boost :-)
>
> Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
>
> Boost has always been "one problem aspect --- one tool" to encourage the developer to mix such specific (often orthogonal) tools into complete solutions. Yes, I know that the the epimorphic direction of that relationship is the one we have focused on mainly, but I argue that even the monomorphic direction is important, i.e., that there is exactly one solution to one *specific* problem aspect.

I actually love more libraries, even if similar, as long as they are
well designed, but I would prefer if they were merged.

Even in my template code I tend to have help functors specified in
template params, but people can override those, and I have a variant
(or base class in some situations) so that they can choose at runtime.
 There are interesting little ways to combine everything, certainly
the usages of StateChart and MSM can be combined in some way, if not,
I still see no problem to have both *AS*LONG*AS* both the pros and
cons of each are listed in *both* of their documentations (the same
reasons in both, so there can be no chance of bias).