Ceptr is built out of Receptors -- lightweight virtual machines which can be organized fractally. This means you can compose new communication and computing patterns out of receptors as coherent building blocks. But receptors themselves are built out of another coherent structure: semantic trees.
Similar to how our body is made out of cells, and the organization of cells is what makes different kinds of organisms. Cells, themselves, are built out of amino-acid complexes at a lower level.
We produced a couple short videos showing how semantic trees work for both DATA and PROCESS for our MIT-KIT Webinar about Ceptr. This blog post just focuses on the excerpt about Semantic trees for data structures and execution of code.
Semantic trees in Ceptr are like the "Words" of a normal CPU. They are our base data unit. So our receptors act as light-weight Virtual Machines, that instead of operating on "32 or 64 bit 'words'" they operate on semantic trees. Our intention here is to try and build meaning in at as low a level as possible in the computing stack. Of course these base units themselves are composed. A regular "word" in a CPU is composed of bits, that the CPU can shift, or add, etc. In Ceptr, we build semantic trees out of named structures, that themselves are compositions of other semantic trees.
In traditional computing, which is built on linear sequences of these "words" we're always serializing and "re-hydrating," we rebuild objects from serializations. We lex & parse our programs into syntax trees to compile or interpret them. In Ceptr we keep meaning and structure connected with the values at the very base level.
It's easy to think of XML (or HTML) as being a semantic tree, but it's actually serial ASCII character representation which we have to interpret to build a tree or a DOM. It's not surprising that we do this, because for the longest time, our primary tool for interacting with the computer has been the text editor, in one form or another. Interestingly Integrated Development Environments almost always try to figure out the tree structures of code on the fly, so as at to be able to provide meaningful hints in the form of syntax highlighting, auto-completion, etc.. (So for us a key step will be to create really good tool-chain and UI for building and manipulating tree.)
We use semantic trees not only to represent data, and code, but they also to hold the execution environment. Traditional computing patterns use a stack to hold function calls by building stack frames that hold a function's parameters a locally scoped variables. In Ceptr we use the idea of a "run tree" which is a self-eating tree that reduces itself to its result. This short video gives a sense of how this works:
For searching and matching data in semantic trees, we've built a generalized form of regular expressions called Semtrex (SEMantic Tree Regular EXpressions). Marc Clifton has put together a detailed article about Semtrex, including a nice piece of code to provide some user interface for building semantic trees and writing semtrex expressions for matching on them. A short description is also available on the API docs page.