Composability and copy/paste safety

Just lost a long message I was just writing to you so I guess I should make this shorter.

I am the creator and maintainer of [Kingly](https://brucou.github.io/documentation/), a state machine library catering mostly to user interfaces, so I am pretty interested in the subject. Follows my feedback.

First of all, wow. You integrated miscellaneous technologies and tools into what seems to be a cohesive tool so congratulations for the end result, it looks good.

On visualization: I like to use [yed](https://www.yworks.com/products/yed) as a visual graph editor for its nice user interface and impressive array of quality automated visualization algorithms. Now I do have some frustrations with the tool, but I found that better than the [PlantUml editor](https://plantuml-editor.kkeisuke.com/), [state-machine-cat]9https://github.com/sverweij/state-machine-cat) and [Cytoscape](https://cytoscape.org/) on real-world graphs. Automatically achieveing an insightful visualization of a graph is a difficult problem and I found that most of the aforementioned tools had troubles with self-loops and backloops to compound states. For small simple graphs though they are great. Cytoscape is open-source and probably the most advanced tool, specially in conjunction with an Elk layout.

References:
- [The Elk layout algorithm](https://github.com/OpenKieler/elkjs), and its [Cytoscape plugin](https://github.com/jfstephe/cytoscape.js-elk)

On textual languages vs. visual languages: there is [a case for textual languages](http://www.cs.um.edu.mt/~synchrone05/Presentations/15-SteffenProchnow.pdf) for sure. A great advantage of textual languages is the ease of copy/paste and replacing functionality, not mentioning navigating/search (and tooling) abilities. However I would believe the advantage is a bit dampened when it comes to state machines, as the latter does not compose so nicely. You can't copy a portion of the graph and paste it elsewhere and be done. There is a range of pitfalls there. The great thing is that you seem to check semantic contracts, which would effectively support copy/pasting as long as the contracts guarantee against the pitfalls. But still, a state links computations to given context. If you copy/paste the state, you are not copy/pasting the context -- which might be exactly what you want, or might be the next bug in your design. Contract checking I think would probably only cover against bad syntax and obvious coherency rules, leaving some room for other mistakes.

References:
- [Kiel: Textual and Graphical Representations of Statecharts](http://www.cs.um.edu.mt/~synchrone05/Presentations/15-SteffenProchnow.pdf)
- [Statechart Development Beyond WYSIWYG](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.6839&rep=rep1&type=pdf)

I recommend you test the language on actual examples. You will find some in Kingly [tutorials](https://brucou.github.io/documentation/v1/tutorials/) and [examples](https://brucou.github.io/documentation/v1/examples/).

Here for instance are machines for a two-player chessgame, evolving from:


to:


It would be great to see how a textual format supports more easily the modification of a design with a view to remove, modify and add features.

I have other examples that are not public yet. If you are interested in that I can send them to you out-of-band.