Revision as of 14:20, 3 December 2024

An "ALD-closure" consists of a sequence of "ALD-lines".
An "ALD-line" consists of a sequence of "ALD-slots" (roughly characters).

Visual rules (to review)

For now this is for the only downward turning vatiant of ALDs. This …
… gives a much more unabiguous mapping between
the codes AST and the semi-visual structure of the AST. … makes for an easier programmatic implementation.

General format in the following:

• [symbol, ok above, ok below, ok left, ok right]

Value wire rules:

• [─ , ANY, ANY, {char,─, ┼, ├}, {char, ─, ┴, ┐} ]
• [┴, {│², ┐}, ANY, {char, ─, ┼, ├}, {char?, ─, ┴, ┐}]

Application wire rules:

• [{┐,╮}, ANY, {│²,┴}, {char,─, ┼, ├}, ANY]
• [│², {│², ┐, │¹}, {│², ┴}, ANY, ANY]

Abstraction wire rules (LS means line start):
Initial section of abstraction wires must be compact (packed from left).

• [│¹, {│¹, ├, ┼}, {│¹, ├, ┼}, {LS, │¹}, {│¹, ├, │²}]
• [├, {LS,│}]

Rules for the leading abstraction section

Abstraction wires {│¹,├, ┼} must be compact (packed from left).
A line with ├ is "active" and enables value operations. Only one ├ per line allowed.
A line without ├ is "passive".
Passive lines preceding lines with more abstraction wires may contain argument names:
– Space-separated list identifying abstraction wires
– An underscore _ marks anonymous arguments
– Trailing unnamed wires (omitted _) are treated anonymous too

Notes on low level ALD transformation operations

Note that these are meant as low level base operations.
UI interface operations should build on them to make for a nice UX.
See "typing normally" section further below for details on that.

Building up and evaluating a lambda calculus based language with some visual transformation rules
may be a really weird and wildly inefficient approach for a programming language. Yes.
A more normal (and in the long run perhaps better) approach would be
a normal lambda calculus evaluator as basis and then a projection function.
Here the focus though is to get from the static mockups here to interactive graphics ASAP with minimal effort.
Conversion/projection from lambda-expression based closures to ALD-closure-diagrams is dauntingly non-trivial.
Especially when wanting to avoid batch processing full redraws.

Here application of visual incremental transfromation rules (that is needed anyway)
should naturally lead to a (very inefficient) way of evaluating the code.
Semi-visual substitution corresponding to beta reduction.

Removing a line

A passive line can always be safely (no semantic changes) removed except
if both adjacent lines (above & below) have more abstraction wires {│¹,├, ┼} than itself. As this would merge distinct abstraction lines.

Removal of an active line means …
★ one needs to (recursively) back-trace across preceding lines to the dependencies
★ one needs to forward-trace across followup lines to dependents It may be code simplifying and usability improving to support / allow-for
forbidden states (tracked and explicit !!). That is, allow for:
– unused value results ┐(╵dead end to below) and
– unfulfilled applications ┴ (╷dead start from above, )
Latter one is feeding in a BOTTOM value outside the expected type (if types are managed). 404 crickets.
The symbol for bottom "⊥" is kinda too close to "┴" so we may want to use an alternative. Idea is to have partial live coding program execution (like in spreadsheets).

Adding a line

TODO

Adding/removing a slot

This may require adding slots in other directly or transitively adjacent lines too. Shifting the ┐will shift the below so far it's not disconnected. Shifting the ┐to the right with no free space " " before a │² will shift the │² (and the follow-up too).

Picking a value from abstractions (or swapping the to a different pick)

Potential for mouse UI:

• Passive line: Click on the application wire to extract the value from.
• Active line: Click on the application wire to switch to. If types are managed induced type mismatches may break wires.
• Click on the argument name further above then on the line where to extract it.
• Click on (or arrow key navigate towards) a line and start typing the desired name (see section "typing normally" below)

Also related here is the potential option of
swapping argument order and corresponding application wires order by drag-n-drop of names or wires.

Picking an application from values

Similar to picking a value from abstractions.
But the position of the line may not allow for access to the desired value that one wants to apply.
Thus the exited line may need to be (auto) re-positioned.
Potentially even needing an introduction of a let … in … structure?

Allowing for application wires crossing over value wires ┼² would be an option but
would lead to a horrible unreadable mess and reduce the uniqueness degree of the visual representation.

Typing normally

Desired interface is not needing to laboriously draw all the wires,
but instead to type as normally as possible
(normally meaning as is establishes in textual code editors).

Typing a function name shall automatically add the corresponding value wire (and abstraction wire if not yet present). Typing an argument name shall automatically add the corresponding value wire on an (as close as possible) preceding value wire line (and abstraction wire if not yet present).

Misc ideas

The shape of the top element of every application wire {┐,╮} could be used
to indicate immediate or delayed evaluation respectively.

Double lined or fat box drawing characters {─, ━, ═}
could be used to indicate the active control flow path.
There are transition characters. Adding a bit of coding complexity.

Edit time immutability

Note that in fully expanded view ALDs shall make their "edit time immutability" explicit.
That is "changing" hard-coded input does not change the diagram
(does not change the active path ═) but instead makes a new diagram.
Shades of gray may gradually change as fancy visual indication that one switched to a different static codebase universe.
An undo history falls out naturally from this.

For a galaxy brain moment: Hard coded input shall extend to the programs (ALDs) structure itself!
And the sequence of edit calculus operations on the AST. Challenging with the approach here.

Side-note: Individual keystrokes may be ephemeral but
hitting enter or jumping elsewhere with arrow keys shall make for an extension of history.

External links

• https://en.wikipedia.org/wiki/Box-drawing_characters