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
On Wed, Feb 3, 2016 at 6:48 PM, Vicente Botet [via Boost] < ml-node+s2283326n4683171h20@n4.nabble.com> wrote: 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-gua... http://boost-experimental.github.io/msm-lite/examples/index.html#dependency-... 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-M... 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-M... Sent from the Boost - Dev mailing list archive at Nabble.com.