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:

  - (DONE) Currently, a basic state is represented in the abstract syntax as an Or-state with no children. Instead, it should be represented as an And-state with no children.
    Rationale:
      - The (flattened) set of states representable by an Or-state is the *sum* of the sets of states of its children. If an Or-state has no children, mathematically its set of states has 0 elements, as 0 is the neutral element for addition.
      - The (flattened) set of states representable by an And-state is the *product* of the sets of states of its children. If an And-state has no children, mathematically its set of states has 1 element, as 1 is the neutral element for multiplication.
      - Since a basic state represents exactly 1 state, an empty And-state is the right way to model it.
    This change will have a positive impact on the complexity of the Rust code generator.

  - (DONE) Better not to model history states as states in the state tree of the abstract syntax. A history state should not occur in the list of children of its "parent". Instead, it is a special property of its parent state, indicating that history is enabled for this state.

  - 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, ...).