SCCD/notes.txt

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

Long-term vision:

  - code generation, work in progress:
    - Rust as a target. Benefits:
      - Very portable:
        - compile to WebAssembly (SCCD in browser!)
        - Rust compiler can produce C-libraries: call from Python, Java, ...
      - Very good performance
        - Zero-cost abstractions (optimize generated code for readability)
            -> "Have your cake, and eat it too"
      - Safety

  - improve action language:
    - highest priority:
      - interfacing with external code only works with Python modules
    - less important, deal with it when it becomes a problem: 
      - statically typed (good), but no generics (bad)
      - user cannot define his/her own types

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

  - Explore per-state data models
      - Right now, there's a single datamodel for the entire statechart. All of the statechart's variables are declared there.
      - We could have datamodels per state: Variables declared in state A's enter actions would belong to A, and be readable/writable by any transition (guard, actions) sourcing from A's substates, as well as the enter- and exit actions of A's substates.
      - The benefit would be composability: 2 statechart models could be merged without having conflicting variables
        - The same non-conflicting merge could also be achieved by automatic renaming, though.
      - Another benefit would be savings on memory consumption: The memory consumed by the datamodel of 2 non-orthogonal states would only be the size of the biggest datamodel, instead of the sum of the 2 datamodels.
      - Conclusion: Could be interesting for very large, composed, statecharts

  - Durations in action language are a single type, consisting of an integer value and a unit. Perhaps it would be better to have a separate duration type for every unit. Especially in Rust it is better to leave the units to the type system, and only work with 'the numbers' in the machine code :)

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