search

boost-ext / sml

C++14 State Machine library
https://boost-ext.github.io/sml
Boost Software License 1.0
1.14k stars 177 forks source link

Advanced hierarchical state machine support #289

Open APokorny opened 5 years ago

APokorny commented 5 years ago

I think SML could have more features on the frontend when it comes to HSM support, because the user can only define transitions within the current compound state - there is now way to nest states in one another and refer to states nested in other states. Within make_transition_table all states are equally leveled substates.

This pushes a bunch of things that could be expressed via hierachy of states into guard logic + entry/exit logic .. or a repetition of transitions.

What about expanding the syntax of make_transition_table - i.e. provide an operator() to state - turning it into a compound state.

APokorny commented 5 years ago

I just realized how that would impact the transition search - i.e it would require a state path search for relevant exit entry actions ... This feels more like a backend rewrite.

erikzenker commented 4 years ago

@APokorny what kind of transitions do you miss? From your description I could imagine the following

I am not sure why these features are missing, but I could imagine that they would maybe increase compile time. The boost msm and hana state machine provide these kind of transitions.

Sulter commented 4 years ago

@erikzenker I think most of those features are not part of UML 2.5, but I'm not a spec lawyer.

erikzenker commented 4 years ago

You mean these features are missing because they are not part of uml 2.5?

APokorny commented 4 years ago

So yeah the first item was the most important one. And UML compatibility is not really important. There are features in UML that I never was able to use. I.e. orthogonal regions. I was always better off designing multiple HSMs that act in parallel.

Then obviously what all of the modern C++ template libraries do wrong is the focus on state machine as hierarchy of compound state. In my experience when you design a system with a HSM you usually build a multitude of charts that do not contradict each other but implement == document a specific aspect. So you need to be able to split out aspects as needed.

I am not sure if I can get around to implement support for splitting the declaration into multiple charts, but currently it seems manageable. So yes I also wrote my own state machine library. HSM is inspired by sml in the frontend, but uses kvasir::mpl to transform the expression list into arrays that are then fed to a state machine interpreter. Most recently driven by the need to do chunk-wise and allocation free processing of large json objects, while not creating that much machine code (raw performance is secondary in this case). There are still quite a few optimizations features I want to add in the future.

Additionally I found the raw performance difference between hana and kavsir::mpl to be an issue for larger state machines - so I moved to the other library early on.

erikzenker commented 4 years ago

So yeah the first item was the most important one. And UML compatibility is not really important. There are features in UML that I never was able to use. I.e. orthogonal regions. I was always better off designing multiple HSMs that act in parallel.

I totally agree. UML does restrict you to much. Skipping UML compatibility makes your life easier.

Then obviously what all of the modern C++ template libraries do wrong is the focus on state machine as hierarchy of compound state. In my experience when you design a system with a HSM you usually build a multitude of charts that do not contradict each other but implement == document a specific aspect. So you need to be able to split out aspects as needed.

You mean that you have your transition table not split into several sub machine, but have a single big transition table that describes all your hierachies?

Additionally I found the raw performance difference between hana and kavsir::mpl to be an issue for larger state machines - so I moved to the other library early on.

Yeah, that is my current problem. IMHO the hana code looks not like black meta programming magic but comes with the price of increased compile time. I created a benchmark where I compared sml, msm, statechart and my hsm. When it comes to runtime my hsm is sometimes faster. But when it comes to compile time hana goes through the roof.

Sulter commented 4 years ago

I totally agree. UML does restrict you to much. Skipping UML compatibility makes your life easier.

I can see that several people feel that way, but does it even make sense to have a SM that you can't draw? The sml documentation stresses how important the compliance is as well.

APokorny commented 4 years ago

Yes we should focus more on describing the SM in charts. Maybe there is a palatable chart description language that can be easily read written and understood. And which can be

My current plan was to just allow multiple descriptions, and combine them afterwards.

erikzenker commented 4 years ago

I can see that several people feel that way, but does it even make sense to have a SM that you can't draw?

You are right. Tools like plant uml have problems to describe these kind of state machines. But every graph drawing tool e.g.: draw.io can handle such diagrams . But imho in the end the library user should decide which features to use. If it makes code easier to write and understand i would use non uml compatible transitions.

erikzenker commented 4 years ago

Yes we should focus more on describing the SM in charts. Maybe there is a palatable chart description language that can be easily read written and understood. And which can be

My current plan was to just allow multiple descriptions, and combine them afterwards.

Yeah. I am interested in your final outcome. For me it is important to have a dense description of the full system which is not cluttert among multiple files. Thus the euml is already a good starting point if you compare it to the classic state pattern.