Skip to content

Compiler vs Runtime program structure dichotomy  #160

Closed
@emil14

Description

Runtime operates on a very primitive structure that basically consist of

  1. ports that describes channels - their names and buffer sizes, they are graph nodes
  2. connections - edges, how those graph nodes are connected (and some details about transferring the data between them)
  3. and effects - first of all operators, maybe something else. computational units where real magic happens

On the other hand compiler operates on a much more complicated structure that envolves entities like: packages, types, interfaces, components. Components itself is pretty complex, they consist of: header, nodes/workers (with configurations like static ports and DI), network.

The meta-programming problem

Right now I'm investigating whether it's possible to introduce some meta-programming machinery. E.g. allow user to write programs that modifies themselves or let the runtime make some modifications for e.g. auto-balancing (horizontal scaling - spawning more operators).

It turns out that it's impossible to provide a runtime API like "import package X" (see #159) or "create new instance of component Y". All updates that can happen are only updates made by using runtime-level abstractions.

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions