Previous post describes code that does functional composition. Let's now add operators that convert this functional composition to become data composition, and allow what is produced to be 'executed later'. Github drop for these code snippet here.
Key insights in writing code this way are:
- Data objects are derived from the functions which define their semantics.
- This is meta-programming 'done backwards'. Like with meta-programming we capture 'what could be interpreted', but we do so through the execution semantics, not by adding an additional meta-language.
- Data objects execution semantics can be ambiguous until ambiguities are removed. Not far from a "quantum-like" execution model!
- There are strong ties here to laziness and trampolining.
- Blockchains are as much about composition of data, as about composition of functions.
These example code snippets are very short (<100 active lines). Two design choices make this possible:
- Focus on arguments, not return value, nor object state
- Make everything composable
What these examples hint at is:
- Return values are really just arguments to further calls.
- Object states are really just arguments, references (e.g. function reference), and contexts of possible further calls.
This is in fact true at the most simple level, such as in the code tied to this posting.
All original content copyright James Litsios, 2021.
No comments:
Post a Comment