Graph model precedents and their limits
Reaktor combines established ideas rather than deriving every system property from a new graph notation. The useful question is which precedent supplies a law for which execution profile, and which assumptions remain Reaktor's responsibility.
| Precedent | What Reaktor takes from it | What remains to establish |
|---|---|---|
| Typed interfaces and Kotlin DSLs | Ordinary functions and receiver builders compose typed structures while keeping normal language expressivity | Runtime authority/effect mediation and target compatibility |
| Port graphs and incidence representations | Connections name endpoints; role slots preserve multi-party relationships | Dialect-specific participation, cardinality and execution laws |
| Open systems and decorated cospans | Explicit boundaries support composition while retaining internal structure | A precise semantics for each Reaktor dialect and legality-preserving adapter |
| MLIR operations, regions, traits and interfaces | An extensible operation vocabulary can expose common properties to analysis/lowering passes | Correctness of Reaktor's specific lowering, source ownership and runtime profiles |
| Synchronous dataflow | Declared production/consumption rates enable scheduling analyses for a restricted stream profile | Those rate and timing assumptions; general actors and Kotlin are outside this restriction |
| Actor and workflow models | State ownership, message processing and durable transitions have explicit operational rules | Delivery, replay, supervision, external authority and compensation guarantees |
| Conventional service and storage contracts | Request/response schemas, conditional writes and idempotent operations mediate real effects | End-to-end behavior across independent failure and trust domains |
Boundaries and algebraic composition
Fong's decorated cospans provide a mathematical construction for composable open systems with internal decoration. Reaktor's use of explicit region boundaries is motivated by this idea. This is an inference about a design direction, not a claim that the current runtime implements that category or inherits every theorem. Decorated Cospans, Brendan Fong.
Composition should preserve identified internal endpoints while exposing only the declared interface. Reaktor additionally needs contract compatibility, effects, authority, clocks, resource ownership and target adapter legality. Those are domain semantics attached to the structure, not consequences of gluing interfaces alone.
Extensible compiler representations
MLIR describes extensible operations, nested regions and traits/interfaces used by generic transformations. It provides a useful industry precedent for an open dialect vocabulary and explicit lowering obligations. Reaktor still needs its own reference behaviors, source maps, target legality checks and differential tests. Linking to MLIR does not mean the Kotlin DSL is compiled through MLIR today. MLIR Language Reference.
Scheduling is profile-specific
Lee and Messerschmitt study static scheduling for synchronous dataflow under specified token rates. A Reaktor stream profile can use that kind of assumption. Arbitrary Kotlin, variable-rate streaming, network effects, actors and human approval do not acquire a static schedule merely because their diagram has edges. Static Scheduling of Synchronous Data Flow Programs.
A graph cycle is therefore a structural fact. The execution profile must say whether it means recursion, a delayed feedback loop, iterative state, repeated events or an invalid combinational cycle.
Kotlin as the host language
Receiver-based DSLs let Kotlin construct nested typed structures without replacing its ordinary language semantics. Kotlin/JS supplies the compatible common-code compilation path. Host embedding, ABI support, resource ownership and export constraints remain explicit integration work. Type-safe builders, Kotlin/JS.
How to judge a new analogy
A useful precedent names the borrowed rule, its assumptions, the relevant Reaktor profile, an executable counterexample when the assumptions fail, and evidence for the target implementation. An analogy without these details can orient a reader, but should not be presented as a system guarantee.