Add ideas from game development group discussions

Command-language.md

@@ -1,20 +1,73 @@
-The dyna3 command language will provide a text-based way to interact with assemblies, parallel to the graphical interface. A mostly-commutative fragment of it will also be used to serialize assemblies. Here are some ideas about how it might be designed.
+The dyna3 command language will provide a text-based way to interact with assemblies, parallel to the graphical interface. A mostly-commutative fragment of it will also be used to serialize assemblies. Here are some ideas about how it might be designed, partly developed in conversation with members of @Vectornaut's game development group.
 
-## Design goals
+## Design
+
+### Goals
 
 - Quick and comfortable to use during interactive sessions.
-- Minimal punctuation.
+- Low barrier to getting started; designed for learning by doing.
 
-## Syntax ideas
+### Refinement
 
-### General principles
+#### Questions
+
+- What should composition look like?
+- Occasionally worth asking: what should the abstract syntax tree look like?
+
+#### Comparisons
+
+- [Tcl](https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+0)
+- [Ruby](https://www.ruby-lang.org/en/documentation/quickstart/)
+- [Bash](https://www.gnu.org/software/bash/manual/bash.html)
+
+## Syntax
+
+### Principles
 
 - **Commands have verbs.** Each command should contain an implicit or explicit verb. It should be easy to learn to look at a command and see what the verb is.
 - **Creation by presumption.** A command that presumes the existence of an element or regulator should create that element or regulator, as long as it’s specified unambiguously and it doesn’t exist already.
 
-### Elements
+### Approaches to design goals
 
-#### Creating elements
+#### Quick and comfortable to use during interactive sessions
+
+- Minimal punctuation.
+- Terse command names.
+
+#### Low barrier to getting started; designed for learning by doing
+
+- Lots of context help.
+- GUI interactions made visible as commands?
+- Clear command names.
+
+### Context help
+
+#### Design considerations
+
+- How much can you disambiguate based on prefixes?
+- Partial expression parsing is crucial. There are many options!
+  - Focus on the last word.
+  - Build a partial syntax tree with markers for missing data.
+  - Come up with multiple continuation options.
+
+#### Thoughts
+
+```
+Sphere
+| Explanation of creation attributes
+```
+```
+Angle a b
+| Add regulator: Angle a b
+| Set regulator: Angle a b @ [value]
+| Unset regulator: Angle a b @ unset
+```
+
+### Thoughts
+
+#### Elements
+
+##### Creating elements
 
 ```
 Sphere
@@ -22,15 +75,15 @@ Sphere
 
 Create a sphere with default parameters and a default ID. The verb in this command is implicit: “[let there be] a sphere.” We can think of this as [copula omission](https://en.wikipedia.org/wiki/Zero_copula). Creating a sphere through the graphical interface should have the same result.
 
-### Observables and regulators
+#### Observables and regulators
 
-#### Referring to regulators
+##### Referring to regulators
 
 Given two elements `a` and `b`, we can refer to the angle between them as `Angle a b`. If the angle is being regulated, we can refer to the regulator in the same way.
 
 We could make regulator references more visually coherent, and help distinguish them from identifiers, by requiring parentheses: `Angle(a b)`. This would be especially helpful for observables with short names, like an `X` observable for the $x$ coordinate of a point. In an expression like `X a`, the observable and the element are visually similar. The form `X(a)` makes it clear that `X` is a regulator.
 
-#### Creating regulators
+##### Creating regulators
 
 _Syntax options_
 ```
@@ -48,7 +101,7 @@ Angle a Sphere
 
 By the **creation by presumption** principle, this should create a regulator for the angle between the element `a` and a new sphere.
 
-#### Manipulating observables
+##### Manipulating observables
 
 ```
 Angle a b ~ 30
@@ -56,7 +109,7 @@ Angle a b ~ 30
 
 Push the angle between `a` and `b` toward 30°. This is analogous to the manipulations you might do by dragging elements in the display. It doesn’t create a regulator, because it’s referring to `Angle a b` as an observable.
 
-#### Setting regulators
+##### Setting regulators
 
 ```
 Angle a b @ 30
@@ -72,11 +125,11 @@ unset Angle a b
 Angle a b @ unset
 ```
 
-Unset the regulator for the angle between `a` and `b`.
+Unset the regulator for the angle between `a` and `b`. The option with `unset` afterward might be more discoverable through context help.
 
-### Identifiers
+#### Identifiers
 
-#### Assigning identifiers
+##### Assigning identifiers
 
 _Syntax options_
 ```
@@ -108,7 +161,7 @@ c named a
 
 Assign the a new identifier, `a`, to the object with the identifier `c`.
 
-#### Nesting identifier assignments
+##### Nesting identifier assignments
 
 _Syntax options_
 ```
@@ -124,3 +177,12 @@ It seems like this should assign the identifier `r` to the angle between `a` and
 - If the language is purely expression-based:
   - An `is` expression could return unit, making it semantically inadmissible for nesting.
   - An `is` expression could require punctuation for nesting.
+
+#### Composition
+
+##### Broad ideas
+
+- To accommodate a flexible verb list, we'll almost certainly need some kind of separators to specify the tree structure. Polish notation won't cut it.
+  - Parentheses are a standard option
+  - Tcl uses [newlines and semicolons](https://www.tcl-lang.org/man/tcltutorial/html/Tcl1.html) to separate commands, whitespace to separate words within commands, and [double quotes](https://www.tcl-lang.org/man/tcltutorial/html/Tcl3.html) and [curly braces](https://www.tcl-lang.org/man/tcltutorial/html/Tcl4.html) for grouping
+- Typically, parser generators can only handle the parts of the syntax that can be turned into parse tables at compile time.