Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-05 15:58:28

On Fri, Feb 5, 2016 at 6:36 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 04/02/2016 11:45, Kris a écrit :
>
>> On Wed, Feb 3, 2016 at 9:59 PM, Vicente Botet [via Boost] <
>> ml-node+s2283326n4683180h99_at_[hidden]> wrote:
>>
>>> A local transition
>>> (
>>>
>>> https://en.wikipedia.org/wiki/UML_state_machine#Local_versus_external_transitions
>>> )
>>>
>>> form an outer state to itself exists from the most inner state but don't
>>> exit from the outer state. If in addition the local transition goes to a
>>> history state the inner state in re-entered.
>>>
>>> I have seen it, thanks. Yea, local transitions are not supported
>> currently
>> by msm-lite.
>> Are they supported by MSM? I haven't seen support for it there too.
>> Anyway,
>> they are
>> not hard to implement. Do you have any important use case for them?
>>
> I don't know what important would mean here. I use them in my daily work
> so that I ensure that I don't exit from a state (representing an activity)
> until the activity is finished. I use to use them with the history state,
> but there are other uses without.
> The implementation is simple and they are part of UML2. I find this enough
> motivating.
>
>>
>> I do get your point now. It's a valid feature. I added a task to
investigate/implement local transitions. However, I can't promise when the
implementation will be done. Firstly, I have to finish the support for
defering events.

>
>> An internal transition don't exits at all.
>>>
>>> I have no preference for the notation, but why not replace the + sign
>>> with a ^
>>>
>>> src ^ event [guard] / action = src
>>>
>>> src ^ event [guard] / action = src(H)
>>>
>>>
>>> Well, I have just followed MSM approach and '+' was used there and I was
>> fine with it.
>> Is there any reason why '+' is wrong and it should be replaced with '^'
>> instead?
>>
> You misunderstood me. + will represent external transitions,  while ^
> could represent local transitions.
>

Yea, I do get it know. Thanks for explanations.

> With
>>>
>>>> action_nexstate approach
>>>> you have to check all actions to verify whether they are not changing
>>>>
>>> the
>>>
>>>> state which might
>>>> be tricky to do. Unless, you have a solution for that?
>>>>
>>> One possibility is to return the next-state.
>>>
>>> You could also restrict the possible next states in the table.
>>>
>>>         s0 + e / action_nextstate(s1, s2)
>>>
>>> I implemented action_nextstate, so please take a look.
>> It might be checked online HERE ->
>> http://melpon.org/wandbox/permlink/IMZUWJpiHDP62WEO
>>
>> It's really easy to implement it, the basic idea below.
>>
>> auto action_nextstate = [](auto... s) {
>>    std::tuple<decltype(s)...> states{s...};
>>    return [=](msm::sm<auto>& sm, auto const& evt, bool external_value) {
>>      action0();
>>      if (some_guard1(external_value)) {
>>        action1();
>>        sm.change_state(std::get<0>(states));
>>      } else {
>>        action2(evt);
>>        sm.change_state(std::get<1>(states));
>>      }
>>    };
>> };
>>
>>
>> I hope that helps.
>>
> I don't know. The syntax is horrible. I would like to be able to use the
> states themselves.
>
> std::get<0>(states) doesn't scale.
>
> Passing all the states each time to the action_nextstate will not be the
> more efficient way.
> The states tuple are part of the lambda so the SM will store the tuple of
> states once for each transition. Even if this is not instantiated for each
> instance of the SM, this seems unnecessary.
>

Fair do's, it ain't perfect. However, it doesn't have to be done this way.
I mean, states don't even have to be passed into action_nextState at all,
which makes the implemention clener and easier to follow.
So, the new version would look like that.

auto action_nextstate = [](msm::sm<auto>& sm, auto const& evt, bool
external_value) {
  action0();
  if (some_guard1(external_value)) {
    action1();
    fsm(sm).set_current_states("s1"_s);
  } else {
    action2(evt);
    fsm(sm).set_current_states("s2"_s);
  }
};

and transition table

    return make_transition_table(
      *"idle"_s + "event"_t / action_nextstate
     , "s1"_s   + "event"_t / [] { std::cout << "in s1" << std::endl; }
     , "s2"_s   + "event"_t / [] { std::cout << "in s2" << std::endl; }
    );

BTW. This version is achieved without any changes to the current version of
msm-lite because setting states is done via testing extension.

Working example here -> http://melpon.org/wandbox/permlink/2SJCL6WAK0n9q7bs

>
> I would suggest to have a single SM context that stores anything needed
> and let each transition have access to it.

I don't like 'God objects'. IMHO, it's way better to inject whatever is
required by guards/actions. It's easier to test and maintain it this way
and there is no need for a SM context in the action_nextState example.

> I do understand your concept, however I'm not sure
>> whether such approach
>> is the best, but, at least, it's easy to implement. I guess if you can
>> prove that this is a common
>> case and that performance might be gained using it then it's worth to
>> consider such practice in general.
>>
> How many times you receive a message and depending on the message contents
> and the SM data context your SM will go to one state or another?
> I don't know how I could prove that this is quite common, but I can ensure
> you that it is ;-)
>
> For performances, there is already the space performances, there is no
> need to store local variable on the state machine context, and this can
> grow quickly.
>
> For runtime, you avoid calling to process event on each transition
> segment, the code of a transition been in a single function the compiler
> can inline, optimize,  ...
>
> Note that I'm not saying that MSM-lite should not support eUML2
> transitions.

Okay, I see your points. I guess usage of action_nextState might be
justified and might be easily implemented in msm-lite too.

>
>
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>