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 <o...@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.
