Last Changed: July 12th, 1997
This is a conversion from Oberon text to HTML, and from German to English. The converter software is still under development,
and some features or information may be missing in this converted version.
HTML hypertext facilities are not yet active in this document.
To exploit the interactive facilities, use Oberon System 3 and the source of this text,
available for download using binary ftp as Oberon System 3 archive.
The converter from German to English is still under development as well.
A previous version is also available for Oberon V4.
To access this and other additional material use
For the convenience of our students, most of this information and the related material is available
in German as well.
Introduction to Oberon
The Oberon Programming Language
Differences between Oberon and Oberon-2
H. Mössenböck, N. Wirth
Institut für Computersysteme, ETH Zürich
Oberon-2 is a true extension of Oberon . This paper summarizes the extensions
and tries to shed some light on the motivations behind them. By that we hope
to make it easier for the reader to classify Oberon-2. For details the reader
is referred to the language report.
One important goal for Oberon-2
was to make object-oriented programming easier without sacrificing the conceptual
simplicity of Oberon. After three years of using Oberon and its experimental
offspring Object Oberon  we merged our experiences into a single refined
version of Oberon.
The new features of Oberon-2 are
type-bound procedures, read-only export of variables and record fields, open
arrays as pointer base types, and a with statement with variants. The for
statement is reintroduced after having been eliminated in the step from Modula-2
Oberon-2 is the result of many
discussions among all members of the Institute for Computer Systems at ETH.
It is particularly influenced by the ideas of Jürg Gutknecht and Josef
Procedures can be bound to a record (or a pointer) type. They are equivalent
to methods in object-oriented terminology. The binding is expressed by a
separate parameter (the operand to which the procedure is applicable, or
the "receiver" as it is called in object-oriented terminology).
Figure = POINTER
FigureDesc = RECORD
w, h: INTEGER
PROCEDURE (f: Figure) Draw; BEGIN
... END Draw;
PROCEDURE (f: Figure) Move (dx,
dy: INTEGER); BEGIN ... END Move;
Draw and Move are bound to Figure which means that they
are operations applicable to Figure objects. They are considered local
to FigureDesc and can be referenced like record fields, e.g. f.Move(10,
10) if f is a variable of type Figure.
Any procedure bound to a type
T is implicitly also bound to all extensions of T. It can be
redefined (overridden) by a procedure with the same name and the same formal
parameter list which is explicitly bound to an extension of T, such
Circle = POINTER
CircleDesc = RECORD
PROCEDURE (c: Circle) Move (dx,
Circle is an extension of Figure. A procedure Move is
explicitly bound to Circle and redefines the Move that is "inherited"
from Figure. Let f be a variable of type Figure and
c a variable of type Circle; then the assignment f := c
makes the dynamic type of f (its run time type) be Circle instead
of Figure. In the call
the variable f serves two purposes: First it is passed as the receiver
parameter to the procedure Move. Second, its dynamic type determines
which variant of Move is called. Since after the assignment f :=
c the dynamic type of f is Circle, the Move that
is bound to Circle is called and not the one that is bound to Figure.
This mechanism is called dynamic binding, since the dynamic type of the receiver
is used to bind the procedure name to the actual procedure.
Within a redefining procedure
the redefined procedure can be invoked by calling it with the suffix ^, e.g.
f.Move^ (dx, dy).
Motivation. We refrained from introducing the concept of a class but
rather replaced it by the well-known concept of records. Classes are simply
record types with procedures bound to them.
We also refrained from duplicating
the headers of bound procedures in the record as it is done in other object-oriented
languages like C++ or Object Pascal. This keeps record declarations short
and avoids redundancy (changes to a header would have to be made at two places
in the program and the compiler would have to check the equality of the headers).
If the programmer wants to see the record together with all procedures bound
to it he uses a tool (a browser) to obtain the information on screen or on
The procedures bound to a type
may be declared in any order. They can even be mixed with procedures bound
to a different type. In Object Oberon, where all methods have to be declared
within their class declaration, it turned out that indirect recursion between
methods of different classes make awkward forward declarations of whole classes
In languages like Object Pascal
or C++, instance variables of the receiver object self can be accessed
with or without qualification (i.e. one can write either x or self.x).
In these languages it is sometimes difficult to see whether a name is an
ordinary variable or an instance variable. It is even more confusing if the
name denotes an instance variable that is inherited from a base class. We
therefore decided that instance variables must always be qualified in Oberon-2.
This avoids having a choice between two semantically equivalent constructs,
which we consider undesirable in programming languages.
In Oberon-2, the receiver is an
explicit parameter, so the programmer can choose a meaningful name for it,
which is usually more expressive than the predeclared name self that is used
in other object-oriented languages. The explicit declaration of the receiver
makes clear that the object to which an operation is applied is passed as
a parameter to that operation. This is usually not expressed in other object-oriented
languages. It is in the spirit of Oberon to avoid hidden mechanisms.
In Object Oberon methods have
the same syntax as ordinary procedures. In large classes where the class
header is not visible near the method header it is impossible to see whether
the procedure is an ordinary procedure or a method, and to which class the
method belongs. In Oberon-2, the type of the receiver parameter of a bound
procedure denotes the type to which the procedure is bound, so no confusion
While in Oberon all exported variables and record fields can be modified
by a client module, it is possible in Oberon-2 to restrict the use of an
exported variable or record field to read-only access. This is expressed
by marking its declaration with a "-" instead of a "*". The "-" suggests
the restricted use of such a variable.
Rec* = RECORD
Client modules can read the variables a and b as well as the
fields f0 and f1, since these objects are exported. However,
they can modify only a and f0; the value of b and f1
can be read but not modified. Only the module which exports these objects
can modify their values. (Even if clients declare a private variable of type
Rec, its field f1 is read-only.) Since b is read-only,
its components are read-only, too.
The motivation behind read-only
export is to allow a finer grain of information hiding. Information hiding
serves two purposes: First, it helps to keep off unnecessary details from
clients. Second, it allows establishing the assertion that the values of
hidden variables are only modified by access procedures of the module itself,
which is important to guarantee invariants. Read-only export supports the
Both in Modula-2 and in Oberon it is possible to have open arrays as parameters.
The length of such an array is given by the length of the actual parameter.
In Oberon-2 open arrays may not only be declared as formal parameter types
but also as pointer base types. In this case, the predeclared procedure NEW
is used to allocate the open array with arbitrary length.
VAR v: POINTER TO ARRAY OF INTEGER;
... NEW (v, 100)
The array v^ is allocated at run time with a length of 100 elements
accessed as v to v.
In Oberon, a with statement is a regional type guard of the form
WITH v: T DO S END
If the variable v is of dynamic type T, then the statement
sequence S is executed where a type guard v(T) is applied to
every occurrence of v, i.e. v is regarded as if it had the
static type T. If the dynamic type of v is not T the
program is aborted. In Oberon-2, the with statement can be written with variants,
WITH v : T0 DO S0
| v : T1 DO S1
If the dynamic type of v is T0, then S0 is executed
and v is regarded as if it had the static type T0; if the dynamic
type of v is T1, then S1 is executed and v is
regarded as if it had the static type T1; else S2 is executed.
If no variant can be executed and if an else clause is missing the program
Although for statements can always be expressed by while statements, they
are sometimes more convenient because they are shorter and termination is
inherent. This is the case if the number of iterations is fixed like in many
applications dealing with arrays. The for statement is written as:
FOR i := a TO b BY step DO statements
This statement is equivalent to the statement sequence
temp := b; i := a;
IF step > 0 THEN
WHILE i <= temp
DO statements; i := i + step END
WHILE i >= temp DO
statements; i := i + step END
 N.Wirth: The Programming Language Oberon. Software Practice & Experience,
 H.Mössenböck, J. Templ: Object Oberon - A Modest Object-Oriented
Structured Programming 10/4: