Pika Constructs

constructs.md

Pika has two constructs, the Description and the Potential.

Description

Properties

• 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.

Dimensions

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.

Potential

Properties

• 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.

Dimensions

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. The Stack 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.

The Name property of the Property makes sense only in the context of unresolved assignations. This raises a question, should unresolved assignations be represented in the abstract syntax tree? My guess it that they should not: so the right path might be to represent assignations as Descriptions which Type has not yet been resolved, similar to promises. Since this is an idea still under development I haven't yet explored the consequences of this approach.

Thinking aloud, it looks like for this to make sense the pending Type may sometimes be an Actualization instead of a Description, rendering the Type dynamic until the Actualization is performed. This is because while regular assignations (assignations of Descriptions) look simplifiable, assignations that point towards an Actualization need the Actualization to be resolved prior for the Type of tht Description to be set.

Corolaries:

• Since all assignations imply redefinition of Type (the Type chain gets larger on each assignation), all references (Description assignations, reference mention, Description definition) may be reinterpreted as Actualizations performed with an empty argument. This makes sense since unifies the concept of Typing.
• If assignations end up being represented with plain Descriptions where the (formerly known as) Property name is the Description name, then it is possible to consider Sequence as a dimension of the Description, eliminate the Property from the Actualization (since the Actualization is now the Type of the "virtual" Description) and finally eliminate the Property construct altogether, leaving just Description and Actualization as default constructs. I like this idea since minimality is a goal for Pika.

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.

This note

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.

bothers me. I think that if the graph it designed no nodes are static and references are actualizations you should not be able to bypass the actualization process and rewrite directly into the Type. I think that there may appear a series of strategies of achieving the same but without breaking the rule of "not direct references, just actualizations", such as:

• Changing the Parent to point to the extended version
• Recurring to the cyclic nature of the graph to add the extension in a different place of the graph.

The point of stopping in a path through the abstract graph is where the path gets trivial, which is at the point where it got periodic (a node pointing to an already-visited node).

This looks like a robust form of terminality representation in directed graphs.

Pending changes to this document:

1. State the cyclic nature of all dimensions, including Sequence.
2. State that all invocations of a Description are stored in the syntax graph as Potentials, even the anonymous ones. Its the garbage collectors' task to make sure that irrelevant anonymous Descriptions are pruned from the graph when no longer needed, not a feature of the abstract graph.
3. State that the Description has no array of properties but rather a reference to the first one. An implementation may provide an accessor to the complete array but in proper terms there is no such array in the graph.

1. Remove the Delegation tree as per Pika: Simplification