Documentation and examples

[brucou]

Frst of all congratulations for bringing life in js to Harel's statecharts formalism. I am looking for sources of documentation and examples to understand the scope of the present library.

I already looked into the SCXML specifications, which is probably the most detailed source of documentation one can find. I was however wondering if the full standard is implemented?

Also examples would be great to grok quickly the behaviour of the library, specifically when it comes to transitions between hierarchical states. If there is any such ressources (in addition to the nice one in SCION_CORE), existing or planned, please let me know.

Depending of what is already been done and tested, I would be interested in contributing ;

• a functional API
  • no actions performed by the state machine (only updates to an encapsulated set of variables that I would call model if the word was not so polysemic)
  • instead the state machine emits output symbols (like state transducers) which serve to encode actions to be taken or events to be sent
• adding plugins dealing with asynchronicity (after I read the specs, it seems it is dealt with somewhat)
• a visualization module

[jbeard4]

Hi,

Thanks for your interest in SCION. I will answer your questions inline below:

I already looked into the SCXML specifications, which is probably the most detailed source of documentation one can find. I was however wondering if the full standard is implemented?

There are some fully compliant SCXML implementations, as determined by conformance to the SCXML IRP test suite [0].

SCION was first implemented in 2010, before the SCXML IRP test suite was released, so implements slightly different semantics than the one described in the Algorithm for SCXML Interpretation in the specification [1]. This wiki document provides an overview of the differences between SCION semantics and SCXML semantics [2]. In particular, SCION does not currently implement SCXML <invoke>.

The next major iteration of SCION will implement the SCXML semantics by default, providing full conformance with the IRP test suite, and deprecate the old SCION semantics. I am planning to publish this release in the near future.

Also examples would be great to grok quickly the behaviour of the library, specifically when it comes to transitions between hierarchical states. If there is any such resources (in addition to the nice one in SCION_CORE), existing or planned, please let me know.

I hope to improve the educational resources around SCXML. Please feel free to email me directly to be informed of these new developments.

Depending of what is already been done and tested, I would be interested in contributing ;

a functional API no actions performed by the state machine (only updates to an encapsulated set of variables that I would call model if the word was not so polysemic) instead the state machine emits output symbols (like state transducers) which serve to encode actions to be taken or events to be sent

You can currently achieve this through the use of state machine "snapshots". After the completion of each call to gen, call "getSnapshot" to retrieve a full copy of the state machine state. On next big-step, create a new scxml.scion.Statechart instance, and rehydrate the old state from the previous snapshot by passing the snapshot as arguments to the Statechart constructor new Statechart(model, { snapshot : snapshot }). In this approach, the SCXML model compiled by SCION and Statechart instance act as a functional state machine transducer which implements the "reaction relation" <snapshot, event> -> new_snapshot.

adding plugins dealing with asynchronicity (after I read the specs, it seems it is dealt with somewhat)

Methods scxml.scion.Statechart.prototype.gen(event) and scxml.scion.Statechart.prototype.start() have equivalent async methods scxml.scion.Statechart.prototype.genAsync(event, cb) and scxml.scion.Statechart.prototype.start(cb). These async methods call setImmediate after each microstep in order to return the thread of control back to the browser.

It looks like I need to document these methods in SCION-CORE's README.

a visualization module

I made two passes at visualization modules [3][4], and an improved visualization module is coming soon.

Please feel free to reach me with any further questions. Thanks.

[0] https://www.w3.org/Voice/2013/scxml-irp/ [1] https://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation [2] https://github.com/jbeard4/SCION/wiki/SCION-vs.-SCXML-Comparison [3] https://github.com/jbeard4/scxml-viz [4] https://github.com/JacobeanRnD/SCHVIZ

[brucou]

Thank you so much for such a detailed and quick answer. I will definitely keep in touch, and I am excited to see that you are still working on implementing this. I reviewed also https://github.com/Touffy/JSSCxml which seems to be almost fully compliant to the specs but abandonned.

A few comments:

• it is possible to nicely visualize compound graph with cytoscape (open-source library for graph visualization) and a specific plugin developed by Bilkent University in Turkey. You can see a demo here : https://codepen.io/davidkpiano/pen/ayWKJO/ and here : https://rawgit.com/cytoscape/cytoscape.js-cose-bilkent/unstable/demo-compound.html. Their github is here https://github.com/cytoscape/cytoscape.js-cose-bilkent (they have a LOT of plugin for manipulating graph through a UI)
  • you probably already have your visualization library, I saw you even do step-by-step simulation (and that's AWESOME), I am giving you those references in case they help you address the visualization challenge
• I have been seeking to apply HFSM to user interfaces, and I developped my own library which implement a specific subset of Harel's statechart semantics. A summary of the problem space (and solution space) can be found here : https://github.com/cyclejs-community/component-combinators/blob/master/documentation/EFSM.md
  • no concurrent states, no history mechanism, and no hierarchy, but handling of asynchronous actions :-) which is why I started to research prior art, before implementing the full statechart formalism
• prior art (applied to the UI problem space)
  • SPROUTCORE (2011)
  • http://blog.sproutcore.com/statecharts-in-sproutcore/
  • http://guides.sproutcore.com/getting_started_2.html
  • https://github.com/etgryphon/stativus (pretty much unmaintained)
  • https://github.com/DavidDurman/statechart
  • only hierarchical states, no concurrent states, or history mechanism
  • a number of finite state machines libraries but no hierarchy, model, guard. or history mechanism

Most importantly all the libraries I found are not functional :

• actions which possibly realize effects can be computed by the state machine
• imperative actions (entry/exit/transition actions) can de facto/implicity use an encapsulated 'model' (also called memory as in finite-memory automata), by leveraging the this property. Explicitly passing that 'model' however has a number of advantages.
  • for a functional implementation, we need output corresponding to input, i.e. a state transducer, i.e not a standard state machine

If I should classify by order of importance the areas of interest when considered from the UI problem space, it would be :

1 visualization of the state-chart 2 step debugger/tracer/simulator 3 hierarchy/history/CONCURRENCY/etc. i.e. the full statechart formalism (yeah that comes third, a standard FSM already covers a nice chunk of the problem space, but it is pretty important for the non-trivial UIs of today)

• management of concurrency is by the far the hardest and the most necessary and sought-for feature for modern UIs. For what I read from SCXML, it does not address the problem as much as Harel's original statecharts (parallel regions but no synchronization points?). Even Harel's statecharts become messy at some level of concurrency, hence the importance of point 1 and 2. 4 model-based testing

Of course, I am interested in not reinventing the wheel, specially if some bright minds already have invested significant time and ressources addressing the problem space, which brought me to your library. All that to explain to you my motivation and how I came to your library.

I will keep in touch. Please let me know also if you have any comments, or if I can help you somehow.