My Mental Coroutines

The following is a collection of tangets I've started or want to explore. But currently have set aside for more important task. This list exist to help me keep tabs on what I wanted to dig into without the mental burden of having them bouncing around my head.

Prototype-based programming

• Look up this dead link: http://www.programming-x.com/programming/prototype-based.html

• Get my hands on Kivo first part information

  Stuff I've already found:

  Kevo -- a language motivated by family resemblances. Perhaps the only object- oriented language that comes closer to the family resemblance model presented by philosophers and cognitive psychologists is Kevo [Tai92, SLS94]. Kevo differs from most other prototype-based object-oriented languages in the respect that it does not support inheritance or delegation in the traditional way. Instead of these and other mechanisms that put a heavy emphasis on sharing and shared properties, Kevo objects are logically stand-alone and typically have no shared properties with each other. (Note that at the implementation level Kevo uses sharing extensively in order toconserve memory, but this is fully transparent to the programmer.) New objects are created by copying, and the essence of inheritance, incremental modification, is captured by providing a set of module operations that allow the objects to be manipulated flexibly. Late binding is used to ensure that methods defined earlier can be overridden to extend existing behavior in an object-oriented manner.

  In order to make it possible to perform modifications to objects not only at the level of individual objects, but also per group, Kevo uses a notion of object (clone) family. An object family is a system-maintained group of objects who are considered to be similar. When objects are modified, the system implicitly moves objects from one family to another, or creates new families as necessary. For instance, when adding new properties to a window object, a new family of objects is created, unless another object with identical properties already exist. Conversely, if the added properties are later removed from the window object, the object will again return to its earlier family (provided that the family still exists). As the criterion of similarity, object interface compatibility is used, meaning that objects are considered to be similar if they have the same external interface/signature. In an ideal situation, object comparison should be based on behavioral compatibility, i.e., ensuring that objects react to external stimuli identically, but in practice coming up with an algorithm that could determine 100% surely and efficiently whether two objects are behaviorally compatible is impossible.

  Object families in Kevo have a conceptual relation to family resemblances presented by philosophers. When combined with the notion of stand-alone objects and the reduced focus on shared properties, this naturally leads to a design and programming style in which advance classification and categorization have a lesser role. Yet even Kevo is still far away from the model mostpresented by prototype theorists who argue that in modeling and classification subjective perceptions have a central role. There is some recent work in the area of subject-oriented programming that aims at taking into account the subjective factors in object-oriented design, but at this point this work is stillly preliminary (see, e.g., [HaO93]).

  concatenative prototyping — the approach implemented by the Kevo programming language — there are no visible pointers or links to the original prototype from which an object is cloned. The prototype (parent) object is copied rather than linked to and there is no delegation. As a result, changes to the prototype will not be reflected in cloned objects.

  The main conceptual difference under this arrangement is that changes made to a prototype object are not automatically propagated to clones. This may be seen as an advantage or disadvantage. (However, Kevo does provide additional primitives for publishing changes across sets of objects based on their similarity — so-called family resemblances or clone family mechanism — rather than through taxonomic origin, as is typical in the delegation model.) It is also sometimes claimed that delegation-based prototyping has an additional disadvantage in that changes to a child object may affect the later operation of the parent. However, this problem is not inherent to the delegation-based model and does not exist in delegation-based languages such as JavaScript, which ensure that changes to a child object are always recorded in the child object itself and never in parents (i.e. the child's value shadows the parent's value rather than changing the parent's value).

  In simplistic implementations, concatenative prototyping will have faster member lookup than delegation-based prototyping (because there is no need to follow the chain of parent objects), but will conversely use more memory (because all slots are copied, rather than there being a single slot pointing to the parent object). More sophisticated implementations can avoid this problem, however, although trade-offs between speed and memory are required. For example, systems with concatenative prototyping can use a copy-on-write implementation to allow for behind-the-scenes data sharing — and such an approach is indeed followed by Kevo. Conversely, systems with delegation-based prototyping can use caching to speed up data lookup.

  archive of hopl entry about Kevo

  Archive of Kevo on Macintosh Repository! But, I do not have access to the system... IT STILL RUNS! It works on infinite mac and I've got the files.

• Write about concatenative prototypes
• Write about proto-OOP in general
• Cecil