Pics Start Date:
Notes Date (end):
TREES / TREES / TREES
There are a bunch of things we've covered since our last core dump... Lots of C development of low-level CEPTR protocols has been happening... structures of nouns and instances, scapes and listeners, logs and "conversations."
But we never built the low-level tree structure which has been hampering progress of building some other "elements" like Lists & Streams (which are actually trees of Patterns/Arrays/Lists/Streams).
As we began to see the tree like structure necessary for our "conversation" logs, we revisited the trees topic and it has leaped into centrality in a whole new and important way.
- Code is a code tree. When we represent it as human readable text it is actually just a human readable serialization format. Properly it is a tree.
- Conversations are signal/event trees
- Data is organized and structured as trees. It's a bit of a falacy that it is in linearly addressable blocks. Natively it is in L1/L2/RAM. RAM is structured on different ranges on chips. Files are stuctured in different blocks in sectors on platters. We normally force it into linear form because our computing models want to relate to it like that. What if we don't have to?
- Trees can contain contents which are again trees in a new context. This could be subaddressed like /3/5/7/0/1/2 (where 0 means entering the contents of the node at 3/5/7 and then navigating /1/2 into its structure)
- Noun Trees and Spec Trees can directly reference the pattern specs of the things they contain
Running an instance of a code tree happens like this:
- Put a pointer to the code tree into the new execution context (like a conversation log ... an HTTP_Request gets logged, so we drop a reference to the HTTP_Request processing code onto the conversation tree which references the signal as its input.
- We crawl the code tree instantiating the ports on our new "stack frame" as we process it.
- We reduce variables and function calls to their actual values as we go
- We slowly transform the code itself to its output. When the code is done running, the state of the tree that's left is the program's output.
We can think of the data engine as waking on a log trigger, matching an appropriate code tree onto a conversation to "process" it. As it runs it prunes itself away until there is only the output which is reintegrated into the data engine..
This feels like a very organic "breath-like" process of expanding and contracting and if it doesn't have the right code-tree to run through the code-reducer... it can go look it up and add it to its repertoire. Receptive capacity.
- Structure of conversation log and its processing states when running through and actually HTTP Request example (New, Open, Pending (parsed?, integrated?), Implanted, Completed).
- Thread safety for processing code trees with multiple threads
Trees, Code Trees, Noun Trees, Spec Trees, Tries, Conversations, Logs,
view (naked) not supported for CD_032+pics