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: Kris (krzysztof_at_[hidden])
Date: 2016-02-03 15:48:14

On Wed, Feb 3, 2016 at 6:48 PM, Vicente Botet [via Boost] <
ml-node+s2283326n4683171h20_at_[hidden]> wrote:

> Le 02/02/2016 22:12, Krzysztof Jusiak a écrit :
>
> > On Tue, Feb 2, 2016 at 6:19 PM, Vicente J. Botet Escriba <
> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=4683171&i=0>>
> wrote:
> >
> >> Le 01/02/2016 11:57, Kris a écrit :
> >>
> >>>
> >> Hi, IIUC you are proposing a 3rd MSM library in Boost, and you don't
> >> pretend to make it a sub-library of Boost.MSM. If I'm right, I suggest
> you
> >> to rename the namespace to msm_lite or whatever you find more
> appropriated.
> >>
> > Fair point, thanks for pointing it out. It's a valid concern. I have
> > nothing against changing the namespace/name as 'msm-lite' is just a
> working
> > title either way. Not sure what the best name should be tho?
> Well, you would need to choose a name ;-)
> >
> >
> >>
> >> Well these are already quite a few features. I have not see local
> >> transitions (different from internal transitions).
> >
> > Yea interna(local) transitions are supported. Example here ->
> >
> http://boost-experimental.github.io/msm-lite/examples/index.html#transitions
> >
> Internal and local transitions are not the same. How do you make
> syntactically the difference. I've not see and reference to local
> transitions.
>
> Actually, I'm not sure what the difference is, sorry. I checked the UML2
spec and there is no much
about local transitions there. Bascially that, 'internal is a special case
of a local Transition that is a self-transition'.
Can you explain how it supose to work, please and what syntax would be
preferable?

> >>
> > Please could you point me if you support choice points?
> >
> > While choice points are unavoidable in graphical UML, I find it not very
> >> useful while writing MSM in C++ as I prefer to do it using if or
> switch.
> >> However having a transition table that can have only one next-state by
> >> transition disable this possibility. I use to have a transition table
> with
> >> a transition that has an action_nextstate that do the action and
> returns
> >> the nextstate of the transition.
> >>
> >> |"s2"_s + event<e2> [ guard ] / action_nextstate This avoids the
> storage
> >> of local variable on the MSM data context. |
> >>
> >>
> >> Have you considered this possibility?
> >>
> > Interesting idea, can you elaborate please as I'm not sure whether I
> follow
> > the idea with the action_nextstate?
> > If it comes to the choice points, I guess the easier way is just to have
> > multiple transitions from the same state?
> >
> > make_transition_table(
> >      s1 -> s2 + e2 [some_guard1 && some_guard2]  / action1
> >    , s1 -> s3 + e2 [other_guard]  / action2
> >    , s1 + e2 / action3
> > );
> >
> > would be the same as
> >
> > if (e2) {
> >    if (some_guard1 && some_guard2) {
> >      action1;
> >      change_state_to(s2);
> >     } else if(other_guard) {
> >       action2;
> >      change_state_to(s3);
> >     } else {
> >       action3;
> >     }
> > }
> >
> This is almost the idea.  But the use case is the followings, sorry I
> will use the src + evt / act = dst notation
>
>
Actually msm-lite, since today, supports almost this syntax. There are
pre/post fix notations available.
src_state + event [guard] / action = dst_state
or
dst_state <= src_state + event [guard] / action

> make_transition_table(
>      s0 + e / action0 -> cp
>      cp [some_guard1] / action1 -> s1
>      cp [else] / action2 -> s2
> );
>
>
> With action-next-state transition could be
>
>       s0 + e / action_nextstate
>
> where action_nextstate is
>
> auto  action_nextstate = [](auto const& evt) {
>      action0;
>      if (some_guard1)  {
>          action1;
>          next_state(s1);  // You could also return a state if there is a
> type that can store any state of the state machine.
>      }  else  {
>          action2;
>          next_state(s2);
>      }
> }
>
> Note that these action-nextstate could define some local variables in
> action0 that can be used in some_guard1 and in action1 and action2 .
>
> The uml transition schema forces to store these local variable on the
> state machine context (or a state context if supported), which is less
> than optimal. This is needed because there is no way to share variables
> between the action0, some_guard1 and in action1 and action2. In addition
> action1 and action2 have no access to the event e, as only the action0
> has it as parameter.
>
> Do you think that this kind of transitions goes against the UML semantics?
>

Hmm, interesting idea. However, it seems to be against the transition table
concept a bit
as guards are hidden in the actions instead. I do understand the concept
tho, it's more
like custom_reaction in the Boost.Statechart. I would still model it using
transition table
because it makes it more visible/clear to understand what is going on. 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?

BTW. msm-lite has a bit different approach than MSM to share the data
because guards/actions
may share data as objects are injected into them when they are required.
For example,

auto action = [] {}; // action, not data, no event
auto action_with_some_data = [] (int i, data& d) {}
auto action_with_some_data_and_event = [] (int i, const auto & event, data&
d) {} // order doesn't matter

auto guard_with_data = [] (data& d, const auto& event) { return true; }

make_transition_table(
  *s1 + e1 [ guard_with_data ] / action = s2
,  s2  + e2 / (action_with_some_data, action_with_some_data_and_event)
);

data d;
sm fsm{d, 42}; // order doesn't matter, this data will be injected into
guards/actions

It's a bit tedious to pass all required objects into state machine
constructor and therefore depenendy injection framework
may become handy here, for example experimental boost.di ->
https://github.com/boost-experimental/di

More examples:
http://boost-experimental.github.io/msm-lite/examples/index.html#actions-guards
http://boost-experimental.github.io/msm-lite/examples/index.html#dependency-injection

Thanks for your feedback, Kris

>
> Best,
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683171.html
> To unsubscribe from [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?, click here
> <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4683016&code=a3J6eXN6dG9mQGp1c2lhay5uZXR8NDY4MzAxNnwtMTY0MTkzNTIwMA==>
> .
> NAML
> <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--
View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683175.html
Sent from the Boost - Dev mailing list archive at Nabble.com.