Visually augmented purely functional programming - Revision history

Apm at 08:42, 5 May 2024

2024-05-05T08:42:58Z

← Older revision		Revision as of 10:42, 5 May 2024
Line 72:		Line 72:
	[[Category:Information]]		[[Category:Information]]
	[[Category:Programming]]		[[Category:Programming]]
			[[Category:Software]]

Apm: added Category:Programming

2021-09-26T08:33:58Z

added Category:Programming

← Older revision		Revision as of 10:33, 26 September 2021
Line 71:		Line 71:

	[[Category:Information]]		[[Category:Information]]
			[[Category:Programming]]

Apm: /* Related / added Annotated lambda diagrams

2021-09-26T05:34:21Z

Related: added * Annotated lambda diagrams

← Older revision		Revision as of 07:34, 26 September 2021
Line 59:		Line 59:

	* '''[[Higher level computer interfaces for deveusers]]'''		* '''[[Higher level computer interfaces for deveusers]]'''
			* [[Annotated lambda diagrams]]
	* [[Programming languages]]		* [[Programming languages]]
	* [[General software issues]]		* [[General software issues]]

Apm: /* Related / added '''Higher level computer interfaces for deveusers'''

2021-07-13T10:13:13Z

Related: added * '''Higher level computer interfaces for deveusers'''

← Older revision		Revision as of 12:13, 13 July 2021
Line 58:		Line 58:
	== Related ==		== Related ==

			* '''[[Higher level computer interfaces for deveusers]]'''
			* [[Programming languages]]
	* [[General software issues]]		* [[General software issues]]
	* [[~~Programming languages~~]]		* [[Software]] – overview page

	== External Links ==		== External Links ==

Apm: /* Related */ added link to: Programming languages

2018-07-17T17:05:33Z

Related: added link to: Programming languages

← Older revision		Revision as of 19:05, 17 July 2018
Line 59:		Line 59:

	* [[General software issues]]		* [[General software issues]]
			* [[Programming languages]]

	== External Links ==		== External Links ==

Apm: Category:Information

2017-07-16T06:07:57Z

Category:Information

← Older revision		Revision as of 08:07, 16 July 2017
Line 65:		Line 65:
	* https://en.wikipedia.org/wiki/Visual_programming_language		* https://en.wikipedia.org/wiki/Visual_programming_language
	* GoogleTechTalk Tangible Functional Programming by Conal Elliott https://www.youtube.com/watch?v=faJ8N0giqzw		* GoogleTechTalk Tangible Functional Programming by Conal Elliott https://www.youtube.com/watch?v=faJ8N0giqzw

			[[Category:Information]]

Apm: /* Program Transformations */ ore -> or

2017-06-21T14:08:57Z

Program Transformations: ore -> or

← Older revision		Revision as of 16:08, 21 June 2017
Line 29:		Line 29:
	'''Drag and drop to:'''		'''Drag and drop to:'''
	* change between tuple-input and separate function parameters -- aka curry/uncurry		* change between tuple-input and separate function parameters -- aka curry/uncurry
	* change the order of the function arguments or the order of the tuple elements (~~selfpropagating~~)		* change the order of the function arguments or the order of the tuple elements (self-propagating)
	* move a helper-function one level more general/global* - or all the way to top level global -- (*if helper functions have helper functions)		* move a helper-function one level more general/global* - or all the way to top level global -- (*if helper functions have helper functions)
	* move a function one level more specialized/local (if used in multiple places independently changeable copies will emerge)		* move a function one level more specialized/local (if used in multiple places independently changeable copies will emerge)
Line 36:		Line 36:
	* consistently rename variables (self propagating) -- aka alpha conversion		* consistently rename variables (self propagating) -- aka alpha conversion
	* substitute variables with their definition -- aka beta reduction		* substitute variables with their definition -- aka beta reduction
	* make anonymous functions explicit ~~ore~~ vice versa -- aka eta conversion		* make anonymous functions explicit or vice versa -- aka eta conversion
	* do simple out of context unit testing <br> decouple a single function argument i.e. replace only one parameter with a test-input <br> decouple all function arguments i.e. replace all parameters with test-inputs		* do simple out of context unit testing <br> decouple a single function argument i.e. replace only one parameter with a test-input <br> decouple all function arguments i.e. replace all parameters with test-inputs
	* open a single function context for visualization and complexity control of function parameters and the helper-function-context <br> [let x1=..,x2=..,xN=.. in -- function_definition(xi,yi) -- where y1=..,y2=..,yN=..]		* open a single function context for visualization and complexity control of function parameters and the helper-function-context <br> [let x1=..,x2=..,xN=.. in -- function_definition(xi,yi) -- where y1=..,y2=..,yN=..]

Apm: added back link to super page in related section

2017-06-14T15:31:03Z

added back link to super page in related section

← Older revision		Revision as of 17:31, 14 June 2017
Line 55:		Line 55:
	In plain lambda calculus all functions without exception have exactly one input and exactly one output.		In plain lambda calculus all functions without exception have exactly one input and exactly one output.
	The most obvious difference of Haskell functions to plain lambda calculus is that all lambdas of a function are in front. This splits the lambda calculus tree at the application nodes (?) (buried lambdas in let-in and where clauses)		The most obvious difference of Haskell functions to plain lambda calculus is that all lambdas of a function are in front. This splits the lambda calculus tree at the application nodes (?) (buried lambdas in let-in and where clauses)

			== Related ==

			* [[General software issues]]

	== External Links ==		== External Links ==

Apm: added two notes regarding relation to haskell

2016-03-04T08:04:07Z

added two notes regarding relation to haskell

← Older revision		Revision as of 10:04, 4 March 2016
Line 24:		Line 24:

	The resulting software production system will be not just applicable to 3D-modelling but to just about any problem including future highly interactive makroscale nanosystems. It may even be a revolution in software development.		The resulting software production system will be not just applicable to 3D-modelling but to just about any problem including future highly interactive makroscale nanosystems. It may even be a revolution in software development.


	== Program Transformations ==		== Program Transformations ==
Line 49:		Line 48:
	Regarding the reverse of beta reduction:		Regarding the reverse of beta reduction:
	* substitute ''equal'' definitions with a new variable -- aka "beta expansion" -- the IDE could try find and show differences that need to be removed to archive extensional equality (equality in the outside behavior not necessarily the inside implementation) but this is an art not a technique since its provable that functions fundamentally can't be tested on equality (halting problem)		* substitute ''equal'' definitions with a new variable -- aka "beta expansion" -- the IDE could try find and show differences that need to be removed to archive extensional equality (equality in the outside behavior not necessarily the inside implementation) but this is an art not a technique since its provable that functions fundamentally can't be tested on equality (halting problem)

			=== Note ===

			This outline is based on a mapping of lambda calculus and a tiny generic bit of Haskell to a graphically augmented programming system.

			In plain lambda calculus all functions without exception have exactly one input and exactly one output.
			The most obvious difference of Haskell functions to plain lambda calculus is that all lambdas of a function are in front. This splits the lambda calculus tree at the application nodes (?) (buried lambdas in let-in and where clauses)

	== External Links ==		== External Links ==

Apm: initial article in pretty good state but far from perfect

2016-03-04T07:54:13Z

initial article in pretty good state but far from perfect

New page

Programming the physical world entails a lot of 3D-modelling. <br>
* 3D-models for production are usually non-interactive.
* 3D-models are usually described with scene graphs which have no notion of time or execution order - they are declarative (animation can be treated statically too - just one more dimension).
This made it easy to create 3D-modelling languages (e.g. OpenSCAD a quasi standard in the RepRap maker community) that build up on scene graphs and remained declarative in nature.

Declarative programming has a number of advantages including guaranteed converging bug-tracking since there are no global implicit cross interactions.
Disadvantages of declarative programming are e.g. difficult to implement random access datastructures and as already mentioned no interactivity. Thus more and more non declarative (imperative) wrapper languages appear that output auto-generated OpenSCAD code.

I'll argue that this is the wrong way to go.
Instead the declarative language OpenSCAD should be upgraded to a fully fledged purely functional programming language (functions treated as values aka functions as "first order citisens").
While retaining the benefits of declarative programming this would thwart the problems:
* advanced functional datastructures -- like in Haskell
* multimedia interactivity -- like Elm (+live program transparency)
* truly scalable graphical programming -- like in Conall Elliotts toy demo Eros

Today's graphical programming languages (2016) are usually considered to be a rather sparse notation
but there's the notion that a picture is worth a thousand words - so clearly we must be doing something wrong.
Images have the capacity to carry more information density than words and are often easier to process by our minds.

Extending on Conal Elliotts concept and elms first order functional reactive programming I think there could be done a lot more.
* the standard program transformations that all programmers regularly do and do way too work intensive without even thinking on it could be simplify to the bare minimum of work.
* a graphical visualization of modern type systems with type inference type-classes types of types (aka kinds) and so on could be made

The resulting software production system will be not just applicable to 3D-modelling but to just about any problem including future highly interactive makroscale nanosystems. It may even be a revolution in software development.

== Program Transformations ==

'''Drag and drop to:'''
* change between tuple-input and separate function parameters -- aka curry/uncurry
* change the order of the function arguments or the order of the tuple elements (selfpropagating)
* move a helper-function one level more general/global* - or all the way to top level global -- (*if helper functions have helper functions)
* move a function one level more specialized/local (if used in multiple places independently changeable copies will emerge)

'''Click to:'''
* consistently rename variables (self propagating) -- aka alpha conversion
* substitute variables with their definition -- aka beta reduction
* make anonymous functions explicit ore vice versa -- aka eta conversion
* do simple out of context unit testing <br> decouple a single function argument i.e. replace only one parameter with a test-input <br> decouple all function arguments i.e. replace all parameters with test-inputs
* open a single function context for visualization and complexity control of function parameters and the helper-function-context <br> [let x1=..,x2=..,xN=.. in -- function_definition(xi,yi) -- where y1=..,y2=..,yN=..]
* open one or all sub-contexts of the in-focus-function (sub-contexts = definitions of the functions which define the in-focus-function) -- (only first layer - no sub sub contexts)
* Open one or all super-contexts of the in-focus-function (super-contexts = the functions which use the in-focus function to define themselves) -- (only first layer - no super super contexts)

Regarding the last two note that:
* breadth search corresponds to divide and conquer "wishful thinking" i.e. assuning that subproblems can be solved and delaying that task for later - applies to both program creation and program execution -- (aka normal order evaluation - lazy evaluation - shortcut evaluation)
* depth search corresponds to constructive buildup from simple building blocks -- aka (application order evaluation eager evaluation)

Regarding the reverse of beta reduction:
* substitute ''equal'' definitions with a new variable -- aka "beta expansion" -- the IDE could try find and show differences that need to be removed to archive extensional equality (equality in the outside behavior not necessarily the inside implementation) but this is an art not a technique since its provable that functions fundamentally can't be tested on equality (halting problem)

== External Links ==

* https://en.wikipedia.org/wiki/A_picture_is_worth_a_thousand_words
* https://en.wikipedia.org/wiki/Visual_programming_language
* GoogleTechTalk Tangible Functional Programming by Conal Elliott https://www.youtube.com/watch?v=faJ8N0giqzw