SCCD/notes.txt

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

Long-term vision:

  - code generation, work in progress:
    - Rust as a target. Very portable:
      - compile to WebAssembly (SCCD in browser)
      - call from Python, Java, ...

  - 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

  - 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:

  - Statechart interface:
      - want YAKINDU style: strict separation between:
        - input events
        - internal events
        - output events
      - each declared with their parameter types

      - in/out/internal events grouped per port
      - operations? also belong to port, or keep separate?

  - CD-part of SCCD:
      - look at ROOM! (Real-time Object Oriented Modeling, Bran Selic)

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