Language Design

From Gevo

Notes regarding programming languages

Comments on existing Languages

Classes enable the programmer to describe the world in terms of equivalence classes. The concept of equivalence classes seems central to emergence and its existence in programming languages implies that the language has mechanisms for managing complexity at multiple scales.

Scripts hide the separation between the description of the model and the instantiation. Therefore, there is no explicit build phase in which to consider component discovery, configuration, dependency resolution etc.

Dependency injection aids autonomy of components by putting the rules for coupling into the local context of the component (object).

C++ and J2EE actually seem to hamper autonomy of instances. C++ applications often seem to result in dependencies that span a large amount of code. Frameworks like J2EE often have external, centralised bureaucratic configuration mechanisms.

Object Machine

If we look at the history of languages we see that there has been an increased support for describing autonomous computation units:

1. starting with assembly language we basically have a linear flow of a large number of instructions
2. to manage the flow we have jump instructions (which show up in Basic as goto instructions)
3. C then introduces higher level instructions and functions to group these blocks of instructions
4. C++ then introduces classes which group functions (methods) and member variables. Importantly the member variables can be instances of other classes. In this way we have hierarchies of self contained objects.
5. Java/Smalltalk build on C++ ideas by adding garbage collection. This means that instances behave more autonomously since their memory resources are managed with them. They also emphasis the object hierarchy by making all classes inherit from Object.

However, issues of process flow control are still left to the program at large and not internalised in the objects. Java begins to address this be introducing object synchronisation, by the flow is still directed externally.

So building on the ideas of virtual machines as seen in Smalltalk and Java, and on the need for autonomous computation units we see that the process flow could be moved into the objects. That is, let each and every object "run in its own thread". That is, from the programming level, every object acts as if it is in charge of its own execution. This is to "threading" as garbage collection is to "memory management": garbage collection means that, at the programming level, it looks like the object is in charge of its own memory resources.

Clearly, the object virtual machine does not need to allocate a separate OS thread to each object. Many objects will be idle most of the time. Only when an object is activated will it need a thread of execution, and even then this could be multiplexed over a pool of OS threads.

Ultimately, this will pave the way to hardware level change. Just like we have dedicated graphics CPUs we could have dedicated object CPUs. These could be massively parallel, enabling massive numbers of objects to execute concurrently. This level of concurrency is not easily achieved with general purpose CPUs, furthermore it is not easily managed without explicit language level support.

Possible Semantics

• all object run concurrently
• all methods are synchronised on the object. That is, for a given object, only one method can be active at a time.
• objects can decide whether to accept or reject a method call
• calls to methods block until the method is accepted. The caller should be able to trigger cancellation (time-out, or external event)
• a method would then return a value asynchronously be invoking a know method on a provided object

Note, this implies that there is no call stack, every method call is an asynchronous hand off rather than pause and resume (push and pop).

One concern with there being no stack, is that there will be no stack trace. Note, however, that the stack trace is in fact a call path. If we consider a 'reject' to be akin to an exception then we can path the the reject follows as it is passed from one object to another.

(If you would like to discuss this further please contact Stewart Gebbie)