Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-17 10:09:29

>> 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).
>
>For the record, back in 2005 I only expressed the opinion that it's not
>possible to implement a purely meta-programming-based FSM framework that
>supports both multi-TU machines and orthogonal regions. This should be
>obvious from the context quoted in the linked message.

I'm happy that you offer to clarify your thoughts because I'm afraid
it isn't that obvious to me.
You brought 2 reasons for this impossibility:
1. Automatic entry/exit. You answer that "With separate FSMs you'd
have to manage this yourself".
2. Automatic event dispatch. You answer that "Again, with separate
FSMs you'd have to do that yourself (dispatch to first FSM and if that
didn't consume the event, dispatch to second FSM and so on)."

Your point was that these 2 cases would have to be managed manually by
the user and I fail to see what this has to do with multiple-TUs.
Could you please explain this as it still seems unclear to me?
Your answer was not about compile-time or recompiling if the structure
of a region or separate FSM was changed, which would have been another
issue and I would perfectly understand and accept this argument.
What I understood from your post is that a full-metaprogramming fsm
would not manage these 2 points because of some statechart-specific
multiple-TU considerations, and I'd be grateful if you could explain
them to me.

>IIUC then MSM does not support multi-TU FSMs and you have so far not
>expressed any plans to support them, right?

I fail to see the difference with Statechart except on the amount of
metaprogramming done.
Please help me on that one, if I changed in Statechart the reactions
typedef in the submachine and thus the submachine header, it would be,
from a recompiling perspective, the same result as a
full-metaprogramming fsm, right?
If this really only is a difference in compile-time, I think this has
already been discussed.

To multiple TUs with MSM:
An application is made of a fsm structure and lots more of user code.
This user code can well be in another TU.
The metaprogramming in the top-level fsm needs the header of a sub-fsm
in order to let the compiler do its job, which is probably also what
Statechart does or am I missing something?
Reading again the explanation in Statechart's doc
(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tutorial.html#SpreadingAStateMachineOverMultipleTranslationUnits),
I found in Camera.cpp:
#include "Shooting.hpp"
Which increases my confusion. It seems that Statechart's top-level fsm
also needs the submachine header, which seems to make the multiple-TU
point moot.

Recompiling is another issue, which you didn't mention at that time
(though it would have been a valid one), so please allow me to discuss
it already now as it's likely that you'll bring this one next.
By moving your submachines' application code into different TUs,
you'll gain some compile-time if the submachine actions or application
code also would cause long compile-times.
You'll also gain that a change in a sub-fsm will not cause all to
recompile but only the TUs of this fsm and the top-level one.
The fact that I put all my submachines into one header doesn't force
you to do the same.
So yes, you probably can't spread the library metaprogramming work
around different TUs, but you can full well spread the application
work. Depending of how much this is, it can reduce your compile-time
or be not visible.
Again, what is concretely the difference with Statechart?

Christophe