schrottkatze/iowo
1
0
Fork 0
forked from katzen-cafe/iowo
Code Pull requests Activity

docs(design): rename command -> instruction

Browse source
This commit is contained in:
multisn8 2024-01-10 21:34:52 +01:00
parent cbbe2c3253
commit 35695537bd
Signed by untrusted user: multisamplednight
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.
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.
- Can have any, even infinite, amount of inputs and outputs.
- Their amounts may or may not be equal.
- 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 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.
@ -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.
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
Merges and simplifies commands in the graph IR.
Merges and simplifies instructions in the graph IR.
== 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
@ -163,11 +163,11 @@ Looks at the graph IR and decides when the VM should execute what.
= Open questions
- @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?
- Not all inputs are order-independent, e.g. `div`
- 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
- Maybe a middle ground, such that at most 1 input is allowed to be positional?
- @pipeline
@ -175,7 +175,7 @@ Looks at the graph IR and decides when the VM should execute what.
- @splitting
- 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?
- 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?
- Shorter
- More ambiguous if only looking at the first char though

2
docs/template.typ
View file

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