schrottkatze/iowo
1
0
Fork 0
mirror of https://forge.katzen.cafe/katzen-cafe/iowo.git synced 2024-11-05 15:26:24 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs(design): rename command -> instruction

Browse source
This commit is contained in:
MultisampledNight 2024-01-10 21:34:52 +01:00
parent cbbe2c3253
commit 35695537bd
No known key found for this signature in database
GPG key ID: C81EF9B053977241
2 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/design/iowo-design.typ
View file

@ -46,16 +46,16 @@ mask
Functional and pipeline-based. Functional and pipeline-based.
However, in contrast to classic shell commands, However, in contrast to classic shell commands,
commands can have multiple outputs and multiple inputs. instructions can have multiple outputs and multiple inputs.
=== Commands === Instructions
The foundation of actually "doing" something. The foundation of actually "doing" something.
- Can have any, even infinite, amount of inputs and outputs. - Can have any, even infinite, amount of inputs and outputs.
- Their amounts may or may not be equal. - Their amounts may or may not be equal.
- Inputs and outputs must have their types explicitly declared. - Inputs and outputs must have their types explicitly declared.
- An command with - An instruction with
- at least one output is called a streamer. - at least one output is called a streamer.
- at least one input is called a consumer. - at least one input is called a consumer.
- _both_ at least one input and at least one output is _both_ a streamer and a consumer, and culminatively called a modifier. - _both_ at least one input and at least one output is _both_ a streamer and a consumer, and culminatively called a modifier.
@ -144,15 +144,15 @@ The parsed representation of the source, and also what the runtime operates on.
In a way, this is the AST, except that it's not a tree. In a way, this is the AST, except that it's not a tree.
It is represented in iOwO using adjacencies, where essentially the vertices#footnote[Nodes or commands in this case.] and their edges#footnote[Connections or pipes in this case.] are stored separately. It is represented in iOwO using adjacencies, where essentially the vertices#footnote[Nodes or instructions in this case.] and their edges#footnote[Connections or pipes in this case.] are stored separately.
=== Optimizer === Optimizer
Merges and simplifies commands in the graph IR. Merges and simplifies instructions in the graph IR.
== Runtime == Runtime
Runs through all commands in the graph IR. It does not have any significantly other representation, and despite its name there's _no_ bytecode involved. Runs through all instructions in the graph IR. It does not have any significantly other representation, and despite its name there's _no_ bytecode involved.
=== Scheduler === Scheduler
@ -163,11 +163,11 @@ Looks at the graph IR and decides when the VM should execute what.
= Open questions = Open questions
- @input - @input
- At which position are arguments injected into command inputs? - At which position are arguments injected into instruction inputs?
- How could that be controlled if set to e.g. the end by default? - How could that be controlled if set to e.g. the end by default?
- Not all inputs are order-independent, e.g. `div` - Not all inputs are order-independent, e.g. `div`
- Should inputs and outputs really be positional? - Should inputs and outputs really be positional?
- Could make more complex commands hard to read - Could make more complex instructions hard to read
- But keyworded could also make code very noisy - But keyworded could also make code very noisy
- Maybe a middle ground, such that at most 1 input is allowed to be positional? - Maybe a middle ground, such that at most 1 input is allowed to be positional?
- @pipeline - @pipeline
@ -175,7 +175,7 @@ Looks at the graph IR and decides when the VM should execute what.
- @splitting - @splitting
- How would one split different outputs into a list? - How would one split different outputs into a list?
- Should outputs that are not thrown into a consumer be automatically displayed in some kind of debug view? - Should outputs that are not thrown into a consumer be automatically displayed in some kind of debug view?
- Or should that be done instead using a debug `show` command or the like? - Or should that be done instead using a debug `show` instruction or the like?
- Should consumers be called sinks instead? - Should consumers be called sinks instead?
- Shorter - Shorter
- More ambiguous if only looking at the first char though - More ambiguous if only looking at the first char though

2
docs/template.typ
View file

@ -42,7 +42,7 @@
"scheduler", "scheduler",
"VM", "VM",
"command", "instruction",
"pipeline", "pipeline",
"input", "argument", "consumer", "input", "argument", "consumer",
"output", "streamer", "output", "streamer",