Advanced Oberon features explained

Fine-grained symbol files (object model)

Separate Compilation and Module Extension, Regis Crelier
Available as compressed postscript.

Abstract

As continuous evolution in hardware results in more powerful computers, new programming techniques and concepts must be developed to master the consequently increasing software complexity. Separate compilation of modules is such a technique that has proven valuable in Modula-2 and in Oberon, among other strongly-typed programming languages.
The module is both the structural unit and the compilation unit of programs. Replacing a module by a new one does not affect the rest of the system, provided that the module interface has not changed. Otherwise, client modules of the modified interface have to be recompiled to maintain system consistency. The last opportunity to detect an inconsistency is when modules are linked to form an executable unit. The check usually consists in comparing, for each imported interface, the expected key of that interface, as known at compilation time of the client, with the key of the effectively supplied interface. A mismatch indicates an inconsistency. This model is simple and efficient, but not very flexible. Indeed, a minor modification of an interface, such as the insertion of a new procedure, can trigger many unnecessary recompilations.
This thesis presents two new models for fine-grained consistency checking and their implementation. These models allow the interface of separately compiled modules to be extended without requiring a recompilation of client modules. This is particularly valuable in systems with dynamic loading, where the clients of a library are not known when the library is revised or extended. Interface editing that does not require client recompilation is not restricted to extensions, since the modification of an existing item does not invalidate clients not using this particular item. Even if they use it in a way that is upward-compatible with the modification, they still do not need a recompilation.
These techniques have been implemented in the Oberon System, but they are neither specific to the Oberon Language nor to the Oberon System. They can be applied to any modular programming system in order to improve its safety, its flexibility, or both. Furthermore, these techniques are not available to the programmer as a separate tool whose use remains optional, but have been fully and transparently integrated into the compiler and module loader. Safety must not be optional.

See Object Model Implementation Notes for the OpenVMS Alpha Oberon System.

Metaprogramming

Metaprogramming in Oberon, Josef Templ
Available as compressed postscript.

Abstract

The term metaprogramming refers to programming at the level of program interpretation, or in other words, to extending the interpreter of a given programming language in an application-specific way. Traditionally, this concept is available only in dynamically typed and interpreted languages such as Smalltalk or Lisp. This thesis investigates the possibilities of metaprogramming in a statically typed and efficiently compiled programming language. In the course of a case study, we introduce metaprogramming facilities for the Oberon programming language and system.
The result is a variant of the Oberon operating environment which allows a seamless integration of useful meta-level facilities. The key to this integration is a generalized notion of persistent objects and object libraries and its application to components of Oberon programs. Types and procedures are considered to be persistent objects collected in a special kind of library, namely a module. We introduce a metaprogramming protocol which allows to manipulate arbitrary data structures based on the notion of object riders. An object rider is an iterator which can be used to scan the components of an object and which can be hierarchically refined to structured components down to an arbitrary nesting level. We introduce also facilities for controlling procedure activations based on the notion of active procedures. An active procedure is a procedure object which has its own instance specific behavior expressed by a message handler. Active procedures can individually respond to invocation messages and perform any c omputation as response.
We investigate the implications of this approach with respect to the overall system structure and to the implementation of critical components of the run-time system, such as the library loader and the garbage collector. A new approach to safe library loading and unloading is introduced as well as a simple finalization technique and a way for optimizing libraries with a large number of objects. We show that the integration of metaprogramming facilities does not introduce undue static or dynamic complexity into the Oberon system. A number of realistic applications serve as proof-by-example of the feasibility of the metaprogramming approach.

The example program Test_PUT.Mod illustrates the use of metaprogramming.