Re: [boost] [msm]exit pseudo state and event

Subject: Re: [boost] [msm]exit pseudo state and event
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-07-29 04:51:50

Hi, 

Maybe I solved the problem.
And of course it keeps your policy.

On Wed, 20 Jul 2011 23:01:53 +0200
"Christophe Henry" <christophe.j.henry_at_[hidden]> wrote:

<...snip...>
> > And UML standard said that internal transitions are not relate to 
> > priority.
> > There are no guaranty that internal transitions are evaluated faster than
> > another (non internal) transitions if they have same start state.
> >
> > Consider fig1.png.
> > Thease two transitions have same priority.
> > At least in UML specification, we don't have a guaranty that
> > which transition would be handled.
> > But one of them would be handled.
> 
> True, the Standard is vague about this, which caused me some headaches ;-)
> My decision on this matter is discussable, so please allow me to explain.
> After thinking hard about it, I came to the conclusion that this was just 
> another variation of the Liskov substitution principle (I do use other 
> sources than the Standard ;-) ).
> In your fig2, State1 is a submachine. Then its internal transitions have a 
> higher priority, right?
> Now imagine I redesign it and make it a simple state (your fig1). Then if I 
> follow your interpretation, the priority will change, thus breaking the 
> implicit contract I had with the state machine which State1 was and my 
> behaviour would silently change.
> This would lead to subtle bugs. In this spirit of this principle, I decided 
> the only logical solution was to treat internal transitions as "more 
> internal" and having a higher priority.
> Of course I also edged my bets and allowed the variation with 
> transition_table ;-)
> 
> > If we want to give the internal transition higher priority,
> > we should write the statemachine like fig2.png.
> > In the case of fig2, only the internal transition would be handled.
> >
> > Do you agree?
> 
> No for the reasons I wrote above, but I can't prove you wrong.
> 
> > But we can control the evaluating order using the Row's sequence.
> > (I think it is out of UML standard.)
> 
> It is, but we won't care too much, right? :)
> 
> > e.g.
> >
> > //    Start     Event         Next      Action     Guard
> > Row < Empty   , cd_detected , none    , none     , internal_guard       >,
> > Row < Empty   , cd_detected , State1  , none     , another_guard        >,
> > or
> > //    Start     Event         Next      Action     Guard
> > Row < Empty   , cd_detected , State1  , none     , another_guard        >,
> > Row < Empty   , cd_detected , none    , none     , internal_guard       >,
> >
> > I'd like to know why internal_transition_table is needed.
> > I think transition_table is enough.
> 
> See above. Yes it's not needed but I find it pretty useful in everyday's 
> life. This is of course a matter of taste.
> 
> >> If you're at implementing stuff for msm, I might consider another 
> >> solution:
> >> - a typedef in the front-end, which will change the reading order of the
> >> table, no to break other's code
> >
> > Thanks for good suggestion.
> > I'd like to consider a little more:)
> 
> Sure :)

I introduced new typedef to statemachine class in front-end.
See 14_GuardEvalOrder.cpp. (Attached file)
class Sm1_ and class State1_ have this new typedef named evaluation_forward.
(Line 72 and 171)

It's a modifier of evaluation order.

If and only if evaluation_forward is defined, 
the transition table's evaluation order becomes from top to bottom.

For your convenience, I prepared two patches. One is for trunk, and the other
is for version1.47.0.

Before applying patch or evaluation_forward is not defined,
the output is below.
-----------------
> Send Event1
Guard1_1_i_2
Guard1_1_i_1
Guard1_4
Guard1_3
Guard1_2
Guard1_1
Guard1_i_1
Guard1_i_2
Guard1
Guard2
Guard3
Guard4
0
-----------------

After applyng patch and evaluation_forward is defined,
the output is below.
-----------------
> Send Event1
Guard1_1_i_1
Guard1_1_i_2
Guard1_1
Guard1_2
Guard1_3
Guard1_4
Guard1_i_1
Guard1_i_2
Guard1
Guard2
Guard3
Guard4
0
-----------------

Of course, state id numbering policy is not changed.

Christophe, after your vacation, could you check it?

Regards,
Takatoshi