We've established that a pico is an object. So, is KRL (the programming language used in picos) an object-oriented language?
Object-oriented languages can be divided into two camps: class-based and prototype-based. Among the class-based languages are Smalltalk, Java, etc. On the other hand, Objective C, JavaScript, etc. are prototype based.
Class and instance
A class specifies behavior and state. Behavior is defined by named methods that do computations and return an object. State is defined by naming instance variables that will each hold a value (generally (a reference to) another object) in memory.
Once the class exists, instances of the class can be created from it. Each such object has the methods and the instance variables defined by its class (and, if there is a class hierarchy, that class's superclasses).
That is how objects come into existence in class-based object-oriented programming languages. The object has a reference to its class.
The class comes first, then the object (said to be an instance of the class).
Prototype and clone
In prototype-based object-oriented programming languages, a new object is made by cloning a pre-existing object. The new object has a reference to its prototype and can inherit methods from it (and its prototype and so on).
The prototype comes first, then the new object.
When a single prototype is used many times to create new objects, the graph produced by the prototype link in each object very closely resembles the graph produced by the class link in every object in a class-based object-oriented programming language*.
Object comes first
A pico is created first; that is, before any behavior or state has been defined specifically for it.
A pico is just an object, a boundary that distinguishes it (and its private state) from the world around it. That which is inside the boundary is private.
Communication with the outside world (including other picos) occurs when a pico receives a message from some outside entity, and when it sends a message to another entity.
Once created, a pico can respond to query messages by constructing a value based on its internal state (as happened with the hello.html query described in the previous post). It returns that value.
The pico may also react to event messages (to be described later) by conditionally taking actions (such as creating a child, or sending messages to other picos, etc.) and changing its internal state. In this is follows the ECA (Event condition action) rule.
Since picos follow the actor model, they are created by action taken by a pre-existing pico. The latter pico becomes the parent of the newly created (child) pico. The new pico has a reference to its parent, but doesn't inherit anything (neither behavior nor state) from it.
Pico as virtual machine
Conceptually, a new child pico is created empty, formless, and void. But in practice, every pico upon creation has three rulesets installed in it. You can think of these as the operating system of a very tiny virtual machine.
Once a pico has been created, its parent will send it messages to have it install additional rulesets so that it can fulfill the purpose of its creation.
Anyone who has an ECI (event channel identifier) to the pico with sufficient rights can install more rulesets into the pico. Once installed, these rulesets give the pico additional functionality, with more behavior and persistent state.
Given an ECI (with sufficient rights), anyone can have the pico create child picos of its own, and so forth. It is easy to create a network of picos that together perform some computation or store some data of interest.
The KRL programming language
To the original question of this post. No, KRL is not an object-oriented programming language.
However, a network of picos is a network of communicating and cooperating objects. The behavior of each pico is determined by the rulesets installed in each.
There is a KRL manual and a partial grammar, for when the reader decides to dig deeper.
KRL is a declarative language
Code written in KRL is organized into files called rulesets. Each ruleset may have a meta section which declares certain things about the ruleset as a whole. It may also contain any number of rules.
Each rule has a select when clause which is declarative. When the pico receives an event message, it is matched up against all such clauses for all the rules in all of its rulesets. Those rules which match will be evaluated as part of the pico's reaction to the incoming event message.
KRL is a functional language
As a programming language, it deals with values. There are literal values and computed values. Either can be bound to a name for convenience in referring to it later. When a function is applied to a value, a new value is computed. Values are not mutated by the language.
This is in contrast with imperative languages which have variables holding values, which can be mutated over time as the program runs.
KRL is an imperative language
Each ruleset can have entity variables. These behave like those in an imperative programming language. They can be assigned values. The value of an entity variable can change from time to time. They can also be removed (cleared).
Unlike most imperative programming languages, entity variables are persistent. Even if the pico engine (the runtime system supporting picos) goes down, when it is brought up again the values of entity variables will be intact.
Thread of execution
In most object-oriented programming languages an object receives the thread of execution when it receives a message and as soon as it sends a message to some other object it gives the thread away to that other object. So, the thread has to be managed.
With picos, received messages are queued up on a bus. Each one is handled in a single thread and runs to completion. This is a very simple way of managing a thread and comes from the actor model.
Notes
* The author remembers attending an OOPSLA session in which the speaker noted that this was a common pattern (in the prototype-based language he spoke of) and described a mechanism for handling it efficiently. As he spoke, he said something and the audience and speaker both realized simultaneously, "Oh, that is just a class." It was a very interesting moment, but you had to be there.
No comments:
Post a Comment