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

Subject: Re: [boost] [msm]exit pseudo state and event
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-07-20 17:01:53

> I'm sorry. I omitted too much information.
> Please let me explain step by step.
>
> 1.When the transition process exiting the substatemachine,
>  We sometimes need if/else transition outside of substatemachine.
> 2.In the case above, we can use the anonymous transitions for else
>  transitions.
>  But we have to write it the top of same start state group in
>  transition table.
>  I think it isn't natural description.
>  And I asked you to change the evaluation order reverse.
>
> And then, you said it's difficult. And you showed me some reasons.
> At that time I didn't know the evaluation order was already documented.
> Hence, I thought changing the order was not big problem,
> I thought it's only implementation problem.
>
> 3.I consider that anonymous transitions for else transition have wider 
> usage.
>  e.g. For implement choice pseudo states using msm.
>
> This is why I said it's not corner case. Sorry for less description.

I get it now. Clearly, it is not a corner case. It's even surprising the 
Standard foresees "else" only for junctions / choices.
This would make sense for other cases.

>> > If my understanding is right, we don't need the following expression.
>> >
>> > struct Empty : public msm::front::state<>
>> > {
>> >    struct internal_transition_table : mpl::vector<
>> >           a_internal < cd_detected , Empty, &Empty::internal_action >
>> >    > {};
>> > };
>>
>> Are you saying we don't need internal transitions? I'd disagree then.
>> They're the best way to implement taking action without changing state.
>
> No. UML's internal transitions are important.
> Msm provides some options to implement it.
>
> Without eUML, functor front-end is preferred.
> http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s03.html#d0e1396
> //    Start     Event         Next      Action     Guard
> Row < Empty   , cd_detected , none    , none     , internal_guard       >,
>
> We can describe internal transitions to set Next to none.
> Is it right?
>
> g_irow is almost same.
> //       Start   Event        Guard
> g_irow < Empty , cd_detected ,&p::internal_guard>
>
> I think they are needed.
>
> I only mean internal_transition_table is not mandatory.
> http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s02.html#internal-transitions
>
> Because we already have the machanism that controls the evaluation order
> from inside substatemachine to outside.

Strictly speaking, no, it's not mandatory. The goals of 
internal_transition_table are:
- ensure the transitions withing it have a higher priority
- make the state more reusable and more useful when reused.

> 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 :)

>> - replacing in dispatch_table reverse_fold by fold to change the reading
>> order if typedef is requesting it.
>> - adding rows (frows) at the top instead of bottom.
>>
>> This leaves us with the hard part, reading the ids in the correct order. 
>> For
>> this, we need to find out which one of the transition table 
>> transformations
>> is the correct one. I didn't look at it yet, but I imagine it could be
>> tricky. Then use it to read the id from up to down.
>>
>> I understand you like this feature, but I need to also consider the 
>> wishes
>> of those who requested me very useful features some time ago and are 
>> waiting
>> for them.
>> So it's also my job to allocate my scarce development time (my evenings)
>> where I think it will be the most useful.
>> For example, the junction pseudo-state you requested seems to me to have 
>> a
>> much higher gain for all of us.
>
> Yes. I understand your situation.
> I agree this request is not high priority.
> And the request is not reasonable enough at this time.

Oh it is reasonable, I'm just trying to build first what will make the most 
people happy. To show my point, I am working on:
- a rewrite of the ugliest parts of eUML, the current state is not 
satisfactory
- support for thread-safe usage, asio usage, etc.
- improving my test coverage
I think we all agree that is is badly needed...

> Also I'd like to know your design philosophy of msm.
> I would ask you some questions.

Sure, but for the record, a big part of it is not from me but from a chapter 
from Dave and Aleksey's book (http://boostpro.com/mplbook). This is the base 
for MSM.

Regards,
Christophe