homoiconicity
Table of Contents
Code, is Data, is Code.
Speaking on a more wholistic scale: Data structures and Algorithms can be interpreted as varying representations of a similar source practicality.
1. towards Macros
For a more practical projection of the concept, trying to understand CRUD with homoiconicity as the seeding context: proceeding with Lisp as the base language for the disbussion.
- Creating would translate to constructing new data structures to represent state.
- Reading larger objects in the state would translate to navigating those structures by traversing the memory via the glue that the language provide (pointers/conses)
- Updating the state would involve manipulating the datastructures either by redirecting the pointers or rewriting the underlying bits being interpreted as data.
- Deletion involves marking those regions of memory to be free for use by other processes.
This is the usual interpretation for most langauges. However, when talking about homo-iconic languages such as lisp where the code is representable as data and vice versa (abstract syntax trees are "trees" and gluing/yielding objects via lambdas), the concept of mutation on data can be extended to manipulating the abstract syntax sub-tree (s-expressions are a convenient representation of this) therefore yielding code that treats code as data, inturn yielding unconstrained code that is just as free as something you'd write from scratch.