SCCD/notes.txt

Notes about the future of SCCD
==============================

Long-term vision:

  - execute SCCD models in web browsers
    - through supporting JavaScript (or TypeScript) as:
        - a port of the runtime
        - a target language
    - through supporting C as target language, and compiling to WebAssembly

  - dynamic creation/destruction of instances (the "CD" part of SCCD)

  - graphical editing of statecharts
    - most likely in diagrams.net ("drawio")
        - convert drawio (XML) models to SCCDXML
        - statechart editing plugin

  - code generation
    - generating portable C code (or: Rust) may be the most flexible option:
      - compile to WebAssembly
      - call from Python, Java, ...

  - improve statechart "interface" definition: in/out event, variables (+ observers?), functions, objects
    -> YAKINDU as inspiration

  - testing framework
     - support white-box testing
     - more expressive test models (like YAKINDU's SCTUNIT)


Random notes:

  - Possible "innovative" performance optimization: immediately after making a transition, based on the new set of current states, already calculate a superset of transition candidates for the next transition.
    Rationale: This will speed up the next transition, as fewer transitions have to be evaluated when generating the set of candidates. The total amount of "calculation time" remains the same, we have merely made some calculations sooner, i.e. after firing the previous transition instead of as part of firing the current one. It is more likely that a "the computer" has resources available after firing a transition, as it may take some time before the next event arrives (user input, a timeout, ...).