docs(design): rename command -> instruction

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

docs/template.typ

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