COLA and Open, extensible object models

For those of you who want some context around the OMeta paper, there is some exciting work being done right now by Ian Piumarta as a member of the Viewpoints Research Institute led by Alan Kay:

cola (aka Idst, Jolt, the SODA langauges [sic], &c.) is an ongoing project to create a springboard for investigating new computing paradigms. Everything in it is late-bound, the intention being that any paradigm (existing or yet to be invented, formal complexity notwithstanding) be easily and efficiently mapped to it and made available to the user. It is a small part (the implementation vehicle) of the reinventing computing project.

An interesting and extremely beautiful place to start understanding the system is to see how it is bootstrapped, as described in Open, extensible object models (Ian Piumarta and Alessandro Warth, 2007):

Programming languages often hide their implementation at a level of abstraction that is inaccessible to programmers. Decisions and tradeoffs made by the language designer at this level (single vs. multiple inheritance, mixins vs. Traits, dynamic dispatch vs. static case analysis, etc.) cannot be repaired easily by the programmer when they prove inconvenient or inadequate. The artificial distinction between implementation language and end-user language can be eliminated by implementing the language using only end-user objects and messages, making the implementation accessible for arbitrary modification by programmers. We show that three object types and five methods are sufficient to bootstrap an extensible object model and messaging semantics that are described entirely in terms of those same objects and messages. Raising the implementation to the programmers' level lets them design and control their own implementation mechanisms in which to express concise solutions and frees the original language designer from ever having to say "I’m sorry".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Related Links

I've collected a list of links relating to this project here.

every design contains decisions that limit

I think this is very interesting work, and I've been playing around with it. However, this design still contains decisions that determine what things are easily possible and not easily possible. The following applies to the model as described and implemented in the paper.

The model depends on using the C stack and has as a design goal complete compatibility with the native calling model. This limits how you might implement concurrency/coroutines/threads (no CPS conversion, trampolines, Cheney on the MTA tricks possible), and limits tail call optimization to whatever your C compiler might provide.

The object model depends on a method caching scheme that uses a hash based on the message selector and the "vtable" of the first argument only. This decision restricts what algorithms you could use to implement multiple argument dispatch since the hash will not depend on the other arguments.

I think it is most compatible with an architecture like the E language. No threads, event driven.