-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes.txt
87 lines (67 loc) · 5.94 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
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
envisioned approach:
- import external functions: type-safe bindings with other language (check IDL?)
- also: declare external types
these types cannot be manipulated within SCCD,
but can be used as parameters for imported functions
-> typical use case: "self" parameter of a method call
- less important, deal with it when it becomes a problem:
- explicit syntactic distinction between pass-by-value and pass-by-reference, like in C/C++/Rust
- statically typed (good), but no generics (bad)
- user cannot define his/her own (complex) 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:
- Apparently Python3's standard library XML parser (ElementTree) also features event-driven parsing. Probably we no longer need 'lxml'.
- Refactor XML parsing code to use domain-specific types for parsing rules instead of tuples, dicts and lists.
- (DONE) Currently event IDs are unique within a CD model. They only have to be unique within a statechart model.
DONE: Events are matched by name in the interpreter, and event names become enum variant identifiers in generated Rust code.
- 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.
- An argument against this, is that variables often serve as "communication" between states, or to "remember" stuff for as long as the statechart runs. Therefore, in many models, they would only be declared at the "root" state. There may not be a need to compose statecharts by merging them into one statechart, if we can instantiate and destroy instances of statechart models at runtime (the "CD" part of SCCD).
- 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, ...).