Thoughts on a bytecode level language to implement an OO language on. Omo - Object/Method Oriented. Everything is an object, and we do things by invoking methods on objects. This invocation passes some objects and returns some objects. There are a small number of different implementation styles of objects (styles of classes). 1/ builtin implementations, such as boolean and code variable 2/ external implementation - e.g. C code 3/ explicit implementations, built using code There are two different objects of type 'boolean'(class Boolean), one we call 'true', one we call 'false'. One of the methods that this type accepts is 'select', which take two objects and returns one of them. The class 'code' accepts the method 'execute', and is passed .... something. So to implement an if statement, we create code objects for the two forks, pass them with the select method to the condition, and invoke the execute method on the result. To implement 'while', we evaluate the condition, then invoke the select method passing body and while loop, and null, and the 'execute' the result. Maybe 'execute' should be passed a 'continuation' code, but it has to return sometime, so why not straight away. So, while X do Y done; becomes X.select(stuff, NOP).execute stuff: Y ; X.select(stuff, NOP).execute ; An explicit implementation provides a piece of 'code' for each method needed for that type. An object of an explicit class contains a list of objects. Some of these objects might be 'variables' but that is not essential. They may well be externally implemented objects. A variable supports two methods, get and set. They return and receive a reference to an object, respectively. A piece of code can contain object identifiers and method names (numbers, whatever). An object identifier can refer to A subobject within the current object. An object imported into the class of the current object. An object passed with the method which called this code A temporary object After a method completes, the object(s) that it returns are assigned to temporary objects so that other methods may access them. So a 'code' starts with -> t1 t2 t3 ... to assign 'names' to passed object (references). Then has multiple Method (I1 I2 I3 I4 ) -> t6 t7 t8 To call method on object I1 passing I2.. returning t6 ... And finally Return (I10 I11 I12) to return some object references. One can imaging that the interpreted might do dependancy analysis and possibly invoke different methods in different threads if they are independant. Question: What about when the dependancy is is sideeffects that cannot be seen from the calling patern. Maybe method with side-effects need to be flagged -- what about methods that don't have side effects, but depend on the side effects of others... Probably just have sync points within the 'code' such that preceding methods must complete before following ones commence. Some methods might return 'pending' objects that in some way refer to a thread which is continuing to evaluate the method. The interpreter would not then wait for that thread to finish until the object was actually needed. e.g. until it is ready to invoke a method, on it, or pass it to another method. Some methods may allow pending objects to be passed in for certain arguments. This could allow easy parallelism. When the last reference to a 'pending' object is dropped, it may be appropriate to let it continue in it's own right, or it may be appropriate to terminate the thread(s) working to evaluate it. This decision would probably depend on whether side effects are expected. There would be some standard external classes, such as string and int32. The distinction between builtin and standard external classes depends on whether the interpreter needs to 'understand' the class, either for proper implementation of explicit classes, or for effective optimisation of code. Multi-threading can be achived in two ways 1/ with OS support, such as Pthreads 2/ by round robining a number of states in the interpreter. 1 is probably fiddly as yet (witness the problems that java seems to have - or is that just for JIT compiling) 2 does not naturally allow for multi-threading in external classes. For 2, we would have to require that external methods either be 'fast' or that they engage in co-operative multi-tasking, and never block. Thus there needs to be a return status which says "I haven't finished yet - call me again on *this* event", which might be selectable, or time, or process-exit, or immediate, or semaphore release. This would presumably cause a thread to be created, and a pending object returned. The event would then be registered as blocking the thread. Semphores probably need to be a builtin class. Some methods will require a semaphore within the object to be Ped before continuing. References to objects will probably be fat, including a reference to the class, and maybe a context. Hopefully dynamic optimisations will reduce the need to always carry a fat pointer, but what about pointers that are embedded in objects, only compile time optimisations will be able to help them. Maybe some objects (types of) have the class pointer in the object, others have it with the pointer,and still others are determined to have a single implementation, and so need no class pointer. Or maybe the context can determine the class ?? A "method" is a name-space-change plus a 'code'. But sub-blocks like to allow local variables, so mini-methods are required, which inherit context. In any context, we need a chain of parent contexts. Many O-O langs have only "object" and "class" (and static "package"). I think that a completely general scheme is needed. Objects can often be 'part' of a larger object, from which some context is needed, and so-on recursively.