Pika has two constructs, the Description and the Potential.
- Name: The name of the Description, a String of text) in programming terminology.
- Properties: The list of statements that comprise the Description. In programming terms, an
Array
of Properties.
The Description lives in a four dimensions world:
- Typing: The Description is possibly an extension from another Description, the Type. This Type properties are retrieved as properties of this very Description, but when written upon, they are written in the local Description so to override but not overwrite. The Type can be acceded by the "Type" message or the special character (still to be determined). When actualizing the Description, the Typing dimension flattens in a single moment as the virtual aggregate Description and its consequently actualized with the Argument. The Type of the Description that results from the Potential of other Description, its Type is the original description. In this sense, there is no assignation of references, just actualization without arguments (the actualized Description gets a new name but keeps all the properties).
When accessing properties of properties of the Type, the same effect occurs as with direct properties: the accessing is done verbatim, but when writing occurs, its performed on a differential of the Type property in the local Description.
In the abstract graph (previous to Potential actualizations) the Type can be a Potential.
Note: All the Type ancestry is accessable via the message "Typing". In both the Type and Typing messages the returned value is a true reference to the original Description, not a "contextualized" one, so changes are reflected directly into the hierarchy.
-
Ancestry: The Description can be embedded in another Description, the Parent, from which properties are recursively retrieved when missing from the local description and the Type. The Parent can be acceded via the "Parent" message. The full ancestry can be seen as a list with the "Ancestry" message.
-
Delegation: When a Description is actualized inside another Description, the actualized form keeps the Parent, adds a step in the Typing and sets the Sequence to the corresponding by the Potential. The Delegate is the context Description where the actualization is performed, the Potential's Caller. The Delegation chain is useful so to locate Descriptions that perform actions related to the Delegate rather than to the parent, enabling something like Swiss inheritance where some properties are imported besides the Type.
-
Sequence: The Description is declared always as a Property of another Description. The list up to the point where this Description's Property can be found is the Sequence, and the Description just before this is known as the "Previous". Both the Previous and the full Sequence are accessible via the "Previous" and "Sequence" messages.
- Subject: A Description which acts as the Type for the potential.
- Argument: A Description which serves as object for the Subject's potential.
- Actualization: The univocal Description which will receive the result of this Potential's actualization.
The Potential has a unique dimension, the Stack:
- Stack: The Potential is actualized within a Description that is not necessarily the parent Description of the potential's Subject; the current Description, which can be also called the Parent of the Potential, is called the
Caller
. TheStack
represents the list of parents of the current Potential and the successive actualizations from which the current one was recursively called. This is the most "transversal" dimension in Pika, and I think a true innovation since no other language gives you the ability to scale back in the call stack and modify a caller. The Caller and the Stack are accessible throw the "Caller" and "Stack" messages.
In the topic of basic constructs, there remains the question of whether Pika hierarchies can be cyclic or not: that is to say, if the abstract "tree" is really a tree or if it is a cyclic graph.
The more traditional way of answering this question is to describe the abstract graph as an acyclic tree and consider that the "root" Description is the one with no parent Description (thus creating a virtual "null" element or, as I see it, violating the neccessity of the properties of Description). A similar proposition would be to use an Actualization as the root element and provide no Anchor (the name for an Actualization property that would be the virtual Description it will generate) (I think now that the names are wrong: the Actualization should be named Potentiality or something like that and the virtual Description it will turn into should be the one called actualization).
I have a more radical solution in mind: to use reflective nodes as terminal nodes. The terminal node could for example be Description which is its own parent, its own type, its own delegate, and the first property of itself. Of course, if reflexivity is allowed that implies that the abstract graph can be cyclic: that being the case, several alternative and workable scenarios appear, such one where two root Descriptions are each other Parent, delegates, and so on.
I wonder if this solution, the reflective one, introduces difficulties in the model. It is to early to tell.