Sorry, I did not catch this thread before. If you are looking for a terse way to describe state machines, you may want to have a look at LRP, a live programming language for nested state machines (for robotics), implemented in Pharo. It seems to have what you are talking about in your mail. It is made for robotics, but in the end can be used for a lot more stuff since it has a clean integration with Pharo. The URL of LRP is http://pleiad.cl/LRP If you have any questions, feel free to ask! -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
On 19 Oct 2016, at 00:44, Otto Behrens <otto@finworks.biz> wrote:
I just meant some syntactically terse way of expressing a state machine so that one can see the logic clearly. Representing a state machine in a graphical way is ideal. We did this once, but the problem is to make the state machine definition resilient to refactorings and changes to the code. What I mean is that compiling something into code is a one way thing; to keep it maintained, one would like to "reverse compile" and draw the state machine from code.
A "correct" DSL would be something like a Harel state diagram, which should be able to express most requirements.