Annotated lambda diagrams visual rules - Revision history

Apm: /* Visual rules (to review) */

2025-09-30T14:34:30Z

Visual rules (to review)

← Older revision		Revision as of 16:34, 30 September 2025
Line 8:		Line 8:
	== Visual rules (to review) ==		== Visual rules (to review) ==

	For now this is for the ~~only~~ downward turning variant of ALDs. This …<br>		For now this is only for the downward turning variant of ALDs. This choice …<br>
	… gives a much more unabiguous mapping between ~~<br>~~		… gives a much more unabiguous mapping between the codes AST and the semi-visual structure of the AST. <br>
	the codes AST and the semi-visual structure of the AST.		… makes for an easier programmatic implementation. Less options and cases. <br>
	… makes for an easier programmatic implementation.

	'''General format in the following:'''		'''General format in the following:'''

Apm: /* External links */ added = Related =

2025-09-30T10:15:27Z

External links: added = Related =

← Older revision		Revision as of 12:15, 30 September 2025
Line 164:		Line 164:
	Allowing for ┼² where an application line bridges over a value line. <br>		Allowing for ┼² where an application line bridges over a value line. <br>
	Adopting this would likely lead to an unreadable mess. <br>		Adopting this would likely lead to an unreadable mess. <br>

			= Related =

			* [[Annotated lambda diagram mockups]]
			* [[Annotated lambda diagram]]

	= External links =		= External links =

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

Apm: added section == Alternative variants ==

2024-12-03T21:18:31Z

added section == Alternative variants ==

← Older revision		Revision as of 23:18, 3 December 2024
Line 156:		Line 156:
	This requires some canvas solutions for local only redrawing for rendering efficiency. <br>		This requires some canvas solutions for local only redrawing for rendering efficiency. <br>
	This enables some options for smooth animations despite the basis on boy drawing characters. <br>		This enables some options for smooth animations despite the basis on boy drawing characters. <br>

			== Alternative variants ==

			Allowing applications coming in from below, adding these additional wire elements ┬,┘╯<br>
			The original unannotated [[lambda diagram]]s featured that option. <br>

			Allowing for ┼² where an application line bridges over a value line. <br>
			Adopting this would likely lead to an unreadable mess. <br>

	= External links =		= External links =

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

Apm at 13:30, 3 December 2024

2024-12-03T13:30:13Z

← Older revision		Revision as of 15:30, 3 December 2024
Line 1:		Line 1:
	{{stub}}		{{stub}}

			== Natural choice for datastructure organization ==

	An "ALD-closure" consists of a sequence of "ALD-lines". <br>		An "ALD-closure" consists of a sequence of "ALD-lines". <br>

Apm: vatiant => variant, me all => be all, staring => starting, establishes => established, and more fixes

2024-12-03T13:27:35Z

vatiant => variant, me all => be all, staring => starting, establishes => established, and more fixes

Apm: added missing parts to the rules

2024-12-03T13:20:32Z

added missing parts to the rules

← Older revision		Revision as of 15:20, 3 December 2024
Line 24:		Line 24:

	'''Abstraction wire rules''' (LS means line start): <br>		'''Abstraction wire rules''' (LS means line start): <br>
	* [│¹, {│¹, ├, ┼}, {│¹, ├, ┼}, {LS, │¹}, {│¹, ├, │²}] (│¹ is one visual appearance of an abstraction wire)		* [│¹, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS, │¹}, {│¹, ├, " ",│²?}] (│¹ is one visual appearance of an abstraction wire)
	* [├, {LS,│}]		* [├, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS,│}, {┼, ─, char, ┐?}]
	~~Initial section~~ of ~~abstraction~~ wires must be ~~compact (packed from left)~~.		* [┼, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS,│}, {┼, ─, char, ┐?}]
			The initial part of a line staring from the line-start LS <br>
			is the only place where application wires are allowed. <br>
			It must me all application wires with no gaps. <br>
			Internally │¹ and │² may be represented differently. <br>

	== Rules for the leading abstraction section ==		== Rules for the leading abstraction section ==

Apm: some improvements

2024-12-03T13:05:23Z

some improvements

← Older revision		Revision as of 15:05, 3 December 2024
Line 13:		Line 13:
	'''General format in the following:'''		'''General format in the following:'''
	* [symbol, ok above, ok below, ok left, ok right]		* [symbol, ok above, ok below, ok left, ok right]

	'''Value wire rules:'''		'''Value wire rules:'''
	* [─ , ANY, ANY, {char,─, ┼, ├}, {char, ─, ┴, ┐} ]		* [─ , ANY, ANY, {char,─, ┼, ├}, {char, ─, ┴, ┐} ]
	* [┴, {│², ┐}, ANY, {char, ─, ┼, ├}, {char?, ─, ┴, ┐}]		* [┴, {│², ┐}, ANY, {char, ─, ┼, ├}, {char?, ─, ┴, ┐}]

	'''Application wire rules:'''		'''Application wire rules:'''
	* [{┐,╮}, ANY, {│²,┴}, {char,─, ┼, ├}, ANY]		* [{┐,╮}, ANY, {│²,┴}, {char,─, ┼, ├}, ANY]
	* [│², {│², ┐, │¹}, {│², ┴}, ANY, ANY]		* [│², {│², ┐, │¹, " "}, {│², ┴, " "}, ANY, ANY] (│² is one visual appearance of an application wire)
			Function arguments are corresponding to abstraction wires.

	'''Abstraction wire rules''' (LS means line start): <br>		'''Abstraction wire rules''' (LS means line start): <br>
			* [│¹, {│¹, ├, ┼}, {│¹, ├, ┼}, {LS, │¹}, {│¹, ├, │²}] (│¹ is one visual appearance of an abstraction wire)
			* [├, {LS,│}]
	Initial section of abstraction wires must be compact (packed from left).		Initial section of abstraction wires must be compact (packed from left).
	* [│¹, {│¹, ├, ┼}, {│¹, ├, ┼}, {LS, │¹}, {│¹, ├, │²}]
	* [├, {LS,│}]

	== Rules for the leading abstraction section ==		== Rules for the leading abstraction section ==
Line 30:		Line 34:
	A line without ├ is "passive". <br>		A line without ├ is "passive". <br>
	Passive lines preceding lines with more abstraction wires may contain argument names: <br>		Passive lines preceding lines with more abstraction wires may contain argument names: <br>
	– Space-separated list identifying abstraction wires <br>		– Space-separated (and or line-break separated) list identifying abstraction wires <br>
	– An underscore _ marks anonymous arguments <br>		– An underscore _ marks anonymous arguments <br>
	– Trailing unnamed wires (omitted _) are treated anonymous too <br>		– Trailing unnamed wires (omitted _) are treated anonymous too <br>
Line 65:		Line 69:
	– unused value results ┐(╵dead end to below) and <br>		– unused value results ┐(╵dead end to below) and <br>
	– unfulfilled applications ┴ (╷dead start from above, ) <br>		– unfulfilled applications ┴ (╷dead start from above, ) <br>
	Latter one is feeding in a BOTTOM value outside the expected type (if types are managed). 404 crickets. <br>		Latter one is feeding in a BOTTOM value outside the expected type (if types are managed). 404: crickets. <br>
	The symbol for bottom "⊥" is kinda too close to "┴" so we may want to use an alternative.		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).		Idea is to have partial live coding program execution (like in spreadsheets).
Line 99:		Line 103:
	would lead to a horrible unreadable mess and reduce the uniqueness degree of the visual representation. <br>		would lead to a horrible unreadable mess and reduce the uniqueness degree of the visual representation. <br>

	== Typing normally ==		== Principle: Typing normally ==

	Desired interface is ~~not needing~~ to laboriously draw all the wires, <br>		Desired for a good interface (UX) is that there's no need to laboriously draw all the wires, <br>
	~~but~~ instead to type as normally ~~as possible <br>~~		But instead that one can "type normally". ("Normally" meaning: As is establishes in textual code editors). <br>
	(~~normally~~ meaning as is establishes in textual code editors). <br>

	Typing a function name shall automatically add the		Typing a function name shall automatically add the
Line 111:		Line 114:
	(and abstraction wire if not yet present).		(and abstraction wire if not yet present).

	== ~~Misc ideas~~ ==		=== Principle: All keystrokes cause visible reactions ===

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

	~~Double lined or fat box drawing characters {─, ━, ═}~~ <br>		Hitting keys and noting happens is extremely frustrating and the quickest way to lose alpha testers. <br>
	~~could~~ be ~~used to indicate the active control flow path~~. <br>		Even for illegal edit attempts there needs to be an instant conspicuous response for why this is not possible. <br>
	~~There are transition characters~~. ~~Adding a bit of coding complexity. <br>~~		(and perhaps suggestions for what to do instead).

	== Edit time immutability ==		== Edit time immutability ==
Line 133:		Line 133:
	Side-note: Individual keystrokes may be ephemeral but <br>		Side-note: Individual keystrokes may be ephemeral but <br>
	hitting enter or jumping elsewhere with arrow keys shall make for an extension of history. <br>		hitting enter or jumping elsewhere with arrow keys shall make for an extension of history. <br>

			== Misc ideas ==

			Double lined or fat box drawing characters {─, ━, ═} <br>
			could be used to indicate the active control flow path. <br>
			There are transition characters. Adding a bit of coding complexity. <br>
			related to section "edit time immutability above"

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

			=== Visual scaling extension ===

			Annotations may be replaced by previews of their ALDs. <br>
			By scaling down by a whole multiple x2 x3 x4 one can match the monospace font grid. <br>
			This requires some canvas solutions for local only redrawing for rendering efficiency. <br>
			This enables some options for smooth animations despite the basis on boy drawing characters. <br>

	= External links =		= External links =

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

Apm: added contents for === Picking an application from values ===

2024-12-03T12:20:37Z

added contents for === Picking an application from values ===

← Older revision		Revision as of 14:20, 3 December 2024
Line 70:		Line 70:

	=== Adding a line ===		=== Adding a line ===

			TODO

	=== Adding/removing a slot ===		=== Adding/removing a slot ===
Line 76:		Line 78:
	Shifting the ┐will shift the below so far it's not disconnected.		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).		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) ===		=== Picking a value from abstractions (or swapping the to a different pick) ===

	~~=== Picking an application from values ===~~

	Potential for mouse UI:		Potential for mouse UI:
Line 87:		Line 86:
	* Click on the argument name further above then on the line where to extract it.		* 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)		* 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 <br>
			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. <br>
			But the position of the line may not allow for access to the desired value that one wants to apply. <br>
			Thus the exited line may need to be (auto) re-positioned. <br>
			Potentially even needing an introduction of a let … in … structure? <br>

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

	== Typing normally ==		== Typing normally ==

Apm: basic page

2024-12-03T12:05:20Z

basic page

New page

{{stub}}

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 ===

=== 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) ===

=== Picking an application from values ===

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)

== 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

← Older revision		Revision as of 15:27, 3 December 2024
Line 6:		Line 6:
	== Visual rules (to review) ==		== Visual rules (to review) ==

	For now this is for the only downward turning ~~vatiant~~ of ALDs. This …<br>		For now this is for the only downward turning variant of ALDs. This …<br>
	… gives a much more unabiguous mapping between <br>		… gives a much more unabiguous mapping between <br>
	the codes AST and the semi-visual structure of the AST.		the codes AST and the semi-visual structure of the AST.
Line 27:		Line 27:
	* [├, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS,│}, {┼, ─, char, ┐?}]		* [├, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS,│}, {┼, ─, char, ┐?}]
	* [┼, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS,│}, {┼, ─, char, ┐?}]		* [┼, {│¹, ├, ┼, " "}, {│¹, ├, ┼, " "}, {LS,│}, {┼, ─, char, ┐?}]
	The initial part of a line ~~staring~~ from the line-start LS <br>		The initial part of a line starting from the line-start LS <br>
	is the only place where application wires are allowed. <br>		is the only place where application wires are allowed. <br>
	It must me all application wires with no gaps. <br>		It must be all application wires with no gaps. <br>
	Internally │¹ and │² may be represented differently. <br>		Internally │¹ and │² may be represented differently. <br>

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

Line 110:		Line 110:

	Desired for a good interface (UX) is that there's no need to laboriously draw all the wires, <br>		Desired for a good interface (UX) is that there's no need to laboriously draw all the wires, <br>
	But instead that one can "type normally". ("Normally" meaning: As is ~~establishes~~ in textual code editors). <br>		But instead that one can "type normally". ("Normally" meaning: As is established in textual code editors). <br>

	Typing a function name shall automatically add the		Typing a function name shall automatically add the