Reflection in Oberon
Johannes Kepler University Linz
Institute for Practical Computer Science
Altenbergerstraße 69, A-4040 Linz
In programs we usually distinguish between the data level and the
program level. Variables are at the data level and can be accessed
by the statements of a program. Modules, types and procedures are
at the the program level. They serve to structure a program but they
are usually not viewed as data. Sometimes, however, programs want to
inspect the entities of other programs at the program level, for
example, in order to answer the following questions:
- What are the field names of a record type T declared
in module M?
- Which procedures are currently active (e.g., when a run-time
trap occurs)? What are the names, types and values of their variables?
- Does the caller of the currently executing procedure have a
variable named "x", and if so, what is its type and value?
Questions like these are considered to be on a meta level. They
treat modules, types and procedures as data. They have to know the
structure of this "data" in order to access (or even modify) their
components. If a programming system supports questions of this kind
we call it a metaprogramming system. If programs can ask these question
also about themselves we call such a system reflective.
Metaprogramming and reflection were pioneered by the languages Lisp
and Smalltalk. In Lisp all programs are treated as data. It is
possible to inspect their structure and even to dynamically build
new programs (higher order functions) that can be executed. In Smalltalk
types are represented as classes and procedures as methods of these
classes. The structure of a class is described in a metaclass of which
the class is an instance. The metaclass information can again be
accessed and even modified. Many other languages allow metaprogramming
in a similar way as it is done in Lisp or Smalltalk (e.g., Self, CLOS,
The original Oberon System offered only a limited degree of reflection.
It provided a module Modules which allowed programmers -
among other things - to inpect information about all loaded modules.
Later a module Types was added which provided basic information
about record types. However, Types was not documented in the
books about Oberon. In his dissertation J. Templ implemented an
experimental version of Oberon for Sun workstations which treated
modules, procedures and record types as data allowing also full
access to their components.
We implemented a module to provide access to run time data structures
and some applications that make extensive use of it (e.g., a post-mortem
debugger, a database interface (provides functionality simlar to
Embedded SQL in Oberon, but without the need for preprocessing), a
heap inspector and a general output module).
Paper at the
6th ECOOP Workshop for PhD Students in Object-Oriented Programming,
Linz, Austria, July 7-8, 1996.