Re: [boost] [msm] Review

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

>I'm out of time (not just the review period but other time constraints)
>for doing a proper review, something I regret. However I would like to
>vote for the acceptance of the msm backend conditional on:
>
>Improvements to documentation to formally and fully describe the msm
>interface.

As already said, I agree to add a reference.

>Inclusion of straight-forward out of the box configurability to support
>large FSMs.

Unfortunately, there is nothing I can do to improve the compilers :(

>Yes, with gcc 4.2.4
>
>  - Did you have any problems?
>
>I couldn't get the euml examples to compile. I'm not sure whether this
>is an environment problem (I was using boost 1.40 on Debian testing) or
>something else. I didn't spend much time investigating.

As stated in the documentation, g++ supports eUML only from 4.3.  It
is therefore normal that you didn't manage it.
eUML support is repeated several times in the documentation.

>My comments have been almost entirely around the back end and the more
>direct front-ends to it. I personally think euml should be a separate
>submission/review, once it is more "review ready". There seem to be
>boost version and compiler version issues in getting even the examples
>to compile. These are quite possibly outside of msm/euml itselfs
>control, but if nothing else, they prevent easy review of euml.
>
>I'm actually struggling with the above, because I think having euml in
>trunk, with tests being run, could facilitate resolving some of these
>issues. Maybe euml could be included as some experimental/example part
>of msm initially?

I'm afraid you're extrapolating a little from your own experience
using the wrong compiler. There were just 2 issues so far. One with
VC8, which has a (documented) weak support for eUML. This issue has
been fixed immediately.
The second is a reported warning on g++, which I was not able to
reproduce and needs more concrete input from Michael.
It doesn't seem sufficient for calling eUML not "review ready".
True, eUML has more limited compiler support and this is documented
too. It doesn't make it less ready.

>I don't generally bombard innocent bystanders with my vague ideas. I
>took asking for a review to be asking for it :-)

The review involves many questions from different people and vague
ideas are hard to address. Fortunately, you clarified afterwards, so
that I can take valuable data from it. Sorry about the wrong start.
It's quite sad because I find a few points quite interesting and they
will flow in the design of the future back-ends or improvements in the
current one.

>In putting together the LAPD implementation I'm using the functor front
>end, but end up creating functors via a few macros that dispatch to the
>objects that do the work. I find they don't need access to anything
>other than the fsm (to post events back to) and the event (to
>access/process anything it contains). I'm fairly happy with that aspect
>of the interface.

If it's bothering you to have the source/target states as argument,
it's trivial for me to add a new row type. I wouldn't want to force
macros on you.

>I haven't tried to do it yet, but it struck me that I could potentially
>use the state types alone (not the object ref parameters) as tags to
>determine which object to dispatch to. If I chose to have objects that
>were 1:1 with states I could - but it wouldn't be part of the fsm
>kernel. Is that concrete enough to make sense?

It is ;-)
I'm just unsure if I follow you. With "object to dispatch to", do you
mean objects in your application? Why not use the state for this? I'm
interested in your use case for future developments.

>No, I don't agree at all. I can't see how you can argue that having
>transitions specified in states as statechart does is less clear than a
>separate transition table, then claim that having enty/exit actions
>specified in states is more clear than having them similarly separated.

Good point, which I need to explain. The problem with Statechart's
approach is that states do the job which should be the state
machine's. This increases the importance of states in Statechart, at
the cost of the state machine, which becomes little more than a
wrapper. It also mixes entry/exit with the rest of the transition.
It's not my reading of the philosophy behind the UML specification.
I think the states have a role, state machines another. State machines
implement the structure of the diagram. States implement
state-specific job, which is much less than the state machines'. Their
jobs are:
- entry/exit
- holding state-specific data (not in the UML standard but still
sounds logical to me)
- (possibly) internal transitions

When you look at a transition table, you see the structure of the
machine and only the structure.
(EUML shows you more, but this is not a classical state machine front-end :) )
AFAIK you didn't complain about not seeing the actions/guards code in
the transition table.

To illustrate the difference of roles, could you please have a look at
the examples iPodSearch or iPodSearchEuml? This is a good example.
Take the state StringFind. Its description would be:
- looks if the string contained in an event is found in the string
contained in the state.
- if found, the state sends the event Found on the current state machine.
- else it sends NotFound.

Note that StringFind has no idea of which fsm it is used in. It only
gets a generic fsm as argument of on_entry.
The same documentation is possible for the other states (Foreach and Insert).

So what do we have? 3 states, perfectly reusable and implementing some
valuable job. And they have no idea of the transition table.
Now imagine that MSM comes in with more states, transform, remove,
push_back, etc.
Using a supporting CASE tool, one could easily build complex algorithms.

>I personally find this response vague

Is this already less vague?
About the CASE tool, I showed an early prototype in the last BoostCon
and plan to start working on it again after the review. I only ask for
some patience (for the tool, the state library concept and the
back-ends) because I'm doing all this at night, so I'm not so fast ;-)
For the moment, the tool only allows defining a complete state machine
and generates MSM1 code from it.

>But why do they need to be part of the transition table based "kernel"?
>Don't pay for what you don't need/use?

True, it is an extra cost. Not a big one though, and with little
influence on the performance.

>Yes. Rather. Sorry for the combination of complex grammar and outright
>incorrect grammar that would seem to have lead to this.

Sorry for my lack of patience due to my several parallel discussions.

>I'm not outright against state instantiation. I can't be. I do really
>like statechart's state instantiation model. However, in the review of
>that library I did ask if there was any way that the costs associated
>with it could be avoided when not strictly needed (when the state
>contains no state-local storage). I'm asking a very similar question
>here, but somewhat more emphatically because this is the Msm (first M is
>important!) and it should surely be able to do this

There are limits to what the first M can do though (besides, you know
what that means to your compiler).
But I now understand the point and find the idea interesting. It'd
probably be possible to instantiate only states with local-storage. It
would require a tag (as I won't be able to rely on sizeof) but it
could be possible.
Thanks for the good point!

>> - make a 3rd one, more dynamic, which I want to do since a while.
>> - make no review until all possible back-ends are done and make
>> everybody wait at least one more year.
>>
>> Do we agree that solution 1 seems the more logical?
>
>Logical from what perspective? Buying votes or producing a good library?
>Politics... ;-)

It's not politics and even less buying votes, but a simple recognition
that each developer will use different features and if he doesn't find
his, he'll simply not use the library.
I'm pretty sure, if I had only proposed a mini-backend, many would
have complained about the lack of features, and they'd be right.
The say 20-40% of UML features which you use won't be the same as what
another developer will use. So, a library needs to support as much as
possible.
I think MSM is a good library as it offers almost all of UML features
at very low runtime cost. The only high cost is the compile-time.

Now it's proven that the concepts of the MPL book were right, that it
was indeed possible to implement at least as much as statechart with
metaprogramming techniques.
That this wasn't evident, as shown here
(http://lists.boost.org/Archives/boost/2005/03/81853.php).
I hope you'll trust me that if I can also implement less ;-)

If I get you right, the only major problem you have with the back-end
is the automatic, unavoidable instantiation of states? Doesn't sound
like an impossible problem to me :)

Christophe