Bootstrapping Objects
Ok, my prototype is slowly moving along, but one thing still alludes me. What is the best set of objects to bootstrap the system with, and which objects should be written on top of the system after the system is running?
The final version of the language was meant to be based on a concept of method inlining. Basically, since most memory accesses are more or less constant events within a message, and even when they’re not, most of the code could be inlined further down the message stack, we could rather than using conventions or making the language very memory neutral/high level, we can instead allow programmers to directly manipulate their objects.
Of course this doesn’t really help us now (the current prototype is based on Squeak, which lacks the effective memory model to warrant using raw memory layouts yet), but even if we did implement this approach, we would still require a more generalized object layer on top of it. For this reason I believe that implementing a more restricted object model is in order.
To start with, I believe the basic object structure will be needed (Objects must be defined by the external system), and from there I will attempt to describe the general structure of the language using the Multi-Method equivalent of delegation (traits). This will include all of the necessary interfaces required to make the language self sufficient post bootstrap (except the Virtual Machine itself which will be rewritten in C or Haskell until the language can compile itself).
There will also be several objects that need to be constructed right from the word go, which includes, roughly, Integers, Floats, Strings, Symbols, Lists/Arrays, Dictionaries, Classes, Traits, and the base level behavioral interfaces that apply to all objects. These objects will be provided from Squeak directly, or will be implemented on a Generic object Squeak class, which can provide all of the necessary behaviour to bootstrap language level objects.
One last point I’d like to make. The behavioral interfaces do not actually apply to Mention objects specifically, but rather describe how the programming environment reacts to objects in general. Any object may be added to the Mention system simply by defining the fundamental interfaces required (essentially just some relative typing information for the dispatch engine), and then it can be used anywhere in Mention that actual Mention objects can be! In-fact, this goes so far in the language that there will very likely be components that do not even encode type information into objects for the sake of performance (no object headers or garbage collection). This is possible if the interfaces do not require any dispatching at runtime (otherwise the lack of type information interfaces will cause compilation errors!).
Anyway, hopefully I’ll have the prototype more or less working soon and you’ll be able to check it out for yourself, though it won’t do very much at the moment;)
– Lorenz