The Tunes HLL Syntax
Language syntax is a matter of conventions. No one expressed any preference yet, and existing languages of interest are many, each with its own completely different syntax.
Syntax matters in as much as we need it to communicate the semantics of the HLL.
One possible approach is to define the HLL as multiple extensions to existing languages, then refine it to obtain cleaner things.
A likely approach with this is to define such an extension first in Scheme or Common Lisp that uses a modified form of their syntax to better express these ideas and to interface to the HLL implemented as a Lisp library.
Sequentiality:
- Textual syntax is sequential just because text is sequential. Other syntax (graphical?) may be structured in a way that easily allows more than one possible sequential reading. However, it looks like some bottleneck forces individual humans to acquire data in a sequential manner, anyway.
- However, sequential syntax still encodes meaning that doesn't have to do with position in the code. So Tunes HLL principles suggest that this sequentiality not be built in to the objects representing the expression, but instead be treated as a normalized encoding of the structure.
Tunes HLL principles encourage the idea of separating abstraction from implementation as a necessity; this subproject infers that to mean that a particular syntax should not be exclusively-coupled to a system. So, Tunes should support multiple syntaxes. This juggling may break given sequencing, and use arbitrary tree/graph manipulations. The graphical interface that structured (graphical or textual) editors propose is enough of a "syntax" to me. (See the Tunes Interfaces subproject for generalizations.)
The preferred syntax for input may not forcibly be the preferred syntax for output. For instance, users generally like free-form keyboard input with name completion, and nicknames, but structured output with full names and color. For the sake of consistency verification, it should be easy to interactively change the syntactic mode.
- The most difficult thing about syntax is to agree.
- The syntax must be as simple as possible.
- It must also be compact, with no unneeded redundances.
- Redundances are allowed to verify structure matching as in
- begin ... end
- if ... then ... elif ... elseif ... else ... {endif}
- for ... in ... do ...
- The sources must be human-writable and human-readable.
- What about having a mode where indentation is a structure indicator?
- We would like to be able to embed any syntax in any other with standard tools.
- What syntax for macros and reflexivity?
- Particularly, how to export/import modules without importing the higher-order parts of the module (defining words).
- Now, when there is some higher-order rewrite (say, some object being redefined), how determine simply what objects get rewritten, and which use the old version? Particularly when it's some extension.
- There should be some clear yet quick way to differentiate the refinement of some existing object from the defition of a new one.
- I propose we define some generic way to define and use higher-order modules (i.e. you can define objects, but also meta-objects/grammar rules/defining words, etc). Then we can have some simple languages (Forth, Scheme, Self, Haskell) implemented as simple modules.
Basic abstractions:
- annotations
- environments as interned symbol->value annotations
- patterns as interned object->environment->new-environment
Basic concretizers: