Structural editor
Closely related but not identical: Projectional editor
Structural code editors are special code editors that only allow to make edits on the code
that are representable in the internal representation of the language (in the AST … abstract syntax tree).
Structural editors can eliminate the entire class of syntax errors
as programs with syntax errors simply cannot be constructed.
Make illegal states not representable.
Contents
Typically also projectional
As conventional plaintext editing does not impose any constraints on what can be typed and what not
structural editing is usually implying projectional editing too but there can be exceptions (see further below).
Vice versa Projectional editing too does not necessarily imply structural editing.
Structural but not projectional – the exception
For the exception: Structural programming that is not projectional programming:
There can be "soft structural editing" that merely instantly shows syntax errors
rather than forbidding and thereby preventing them in the first place.
Such "soft structural editing" could be done as an add-on in existing textual code editors.
Structural editors may deliberately allow syntax errors
for the sake of more natural typing.
As these (if these) visually verbous syntax errors are not storable in the internal core representation they are ephemeral i.e. not permanently stored.
Structural and projectional – the typical case
In a projectional editor the code editing interface code representation
is not the source of truth but rather the internal representation is.
Thus illegal structural states such as syntax errors can at best be displayed ephemerally on the editing interface.
They will not get stored and persisted in the internal code representation because they simply have no means for representation there.
Some illegal code structures deserve representability in the internal code representation though.
This is because crossing illegal states is often the fastest path to the target.
A good example here are typed holes in programs.
What to avoid
Badly designed structural editors can feel very frustrating
giving a steep learning curve and may not even be practically usable.
Bad design choices to absolutely avoid include:
- not typing normally
- nonstandard key bindings (enter space tab arrows … these should behave normally instead)
- cursor jumping to hard to predict places
- cursor jumping around in leaps of different sizes
- autocomplete suggestion-box-dropdowns and other info-popups shifting stuff around
- unusual interface choices
When you type something there should always be a helpful response. Never no response.
Getting ones intent into the program should not be harder than via conventional text editing.
Examples
Excellent prototype one line interface:
- https://tylr.fun
- lamdu, hazel, ... almost all (but not all) projectional editors are also structural editors
- Here's a list: https://github.com/yairchu/awesome-structure-editors/blob/main/README.md
- (TODO: Find an example of a structural editor that is not a projectional editor. Like a text editor plugin that highlights syntax errors instantly.)
- Classical box and wire visual programming languages
- Toy languages like e.g. scratch.
Counterexamples
The unison programming language has projectional editing but it does not have structural editing.
At least it's first and current (2022-12) type of code projection is such.
Code is dumped from the internal representation database out to plaintext file.
And there structural rules are typically not being imposed.
Related
- Programming languages
- Software
- Annotated lambda diagrams and Annotated lambda diagram mockups – also a code projection
- Higher level computer interfaces for deveusers
