From 7ee0ab82392be5ee4e1b0e6d603d5b5f9c56d983 Mon Sep 17 00:00:00 2001 From: MultisampledNight Date: Wed, 10 Jan 2024 21:34:52 +0100 Subject: [PATCH] docs(design): rename command -> instruction --- docs/design/iowo-design.typ | 18 +++++++++--------- docs/template.typ | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/design/iowo-design.typ b/docs/design/iowo-design.typ index 9646ab8..fc0069d 100644 --- a/docs/design/iowo-design.typ +++ b/docs/design/iowo-design.typ @@ -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 diff --git a/docs/template.typ b/docs/template.typ index 712c6e7..8059e5c 100644 --- a/docs/template.typ +++ b/docs/template.typ @@ -42,7 +42,7 @@ "scheduler", "VM", - "command", + "instruction", "pipeline", "input", "argument", "consumer", "output", "streamer",