The Oberon Programming Language

Oberon is a general-purpose programming language that evolved from Pascal and Modula-2. This evolution included improvements such as garbage collection, a streamlined module concept, numeric type inclusion, and null-terminated strings, but Oberon's principal unique feature is the concept of type extension. Type extension makes Oberon an object-oriented language. However, Oberon's approach to object-orientation differs considerably from that of other extensions of Pascal or Modula-2. Oberon implementations for DOS, Windows, Amiga, Mac, and UNIX are available via anonymous ftp from ftp.inf.ethz.ch (129.132.101.33) subdirectorypub/Oberon.

The most important difference between Pascal and Modula-2 is the decomposition of programs into modules. In Oberon, a program is an extensible set of modules; in other words, there is no main module. The unit of program execution in Oberon is the "command," an exported, parameterless procedure. Thus, a module in Oberon is:

• The construct for expressing data abstraction by means of an import/export mechanism, like in Modula-2.
• The unit of compilation, including type checking across module boundaries.
• The unit of program extension. A module is supposed to be loaded on demand whenever it is used first.
• A container of commands which may be activated from the operating environment.

Inappropriate deallocation of dynamic storage is a well-known source of catastrophic program failures. In the context of nonextensible applications, such as statically linked programs, this problem can (in theory) be mastered by a careful programmer; for extensible programs, it cannot! There is always the possibility that a module may be added to a program later on; such an extension can introduce additional references to objects of which the implementor of the core modules is unaware. Therefore, Oberon neither requires nor allows explicit deallocation of dynamic storage. Instead, it assumes a conceptually "infinite heap." As in Lisp or Smalltalk, this concept can be implemented on today's finite hardware by a garbage collector which knows about the internal structure of objects and the roots where objects are anchored. Unused objects can be identified and deallocated automatically and safely. This facility makes Oberon programs very reliable, significantly decreasing debugging time. Automatic garbage collection is possible in Oberon because Oberon replaces typing loopholes such as records with variant parts with the type-safe concept of "record extension."

Oberon's basic types are fairly familiar: BOOLEAN, CHAR, SET, SHORTINT, INTEGER, LONGINT, REAL, and LONG-REAL. Between the numeric types, there is a type-inclusion relation: The larger type includes the smaller ones.

With LONGREAL, REAL, LONGINT, INTEGER, and SHORTINT, assignment from a smaller to a larger type is allowed. Operations between different numeric types yield the larger type as result.

SET is a rather crude approximation of the mathematical set concept. It denotes the power set of the integers between 0 and MAX(SET), which is an implementation-dependent constant (typically, 31).

In addition to the basic types, Oberon allows construction of user-defined types by means of the type constructors ARRAY, RECORD, and POINTER. Unlike standard Pascal, however, Oberon offers the type constructor PROCEDURE, which defines procedure types. For example, TYPE Poly2 = PROCEDURE (x0, x1, x2: REAL): REAL; introduces a procedure type denoting quadratic polynoms. Variables of type Poly2 can have as values procedures with appropriate parameters. Procedure variables introduce a level of indirection for procedure calls and can be used to express dynamic binding--a prerequisite for object-oriented programming.

On the other hand, TYPE String = ARRAY 32 OF CHAR; defines a new type String as an array of 32-character elements indexed from 0 to 31. In contrast to Pascal, the lower bound is always 0, for several reasons:

1. Open arrays already start at index 0 in Modula-2.
2. The MOD-operator (positive remainder) yields results including 0. Lower bounds at 0 fit perfectly, for example, for an implementation of a cyclic buffer.
3. There is a nice invariant when iterating over an array.The control variable contains the index of the next element to visit as well as the number of already visited elements.

In contrast to Pascal, Oberon lets you declare formal parameters as open arrays without specifying the number of elements. Such procedures can be called with arrays of arbitrary length as actual parameters. Unlike Modula-2, Oberon allows you to specify multidimensional open arrays.

String literals are compatible with arrays of characters. String assignment and comparison are defined within the language, based on the assumption that strings are always null-terminated.

Record-type constructors such as TYPE T = RECORD x: CHAR; y: INTEGER END, are similar to those in Pascal except that variant records have been replaced by record-type extension. This means that a new record type can be defined as an extension of an existing one. For example, in TYPE T1 = RECORD (T) z: REAL END;, type T1 is said to be a direct extension of type T, which is a direct base type of T1. The extended type inherits all fields of the base type--everything that can be done with the base type can also be done with the extended type but not vice versa. Therefore, Oberon allows you to assign variables of an extended type to variables of the base type.

In contrast to Pascal's variant records, record extension is an open-ended construct; an extended record may well be defined in a module other than the corresponding base type. Surprisingly, record-type extension suffices to make Oberon an object-oriented language.

The code TYPE P = POINTER TO T; is similar to Pascal's ^T. POINTER TO T constructs a new pointer type that denotes references to variables of type T. Pointer types inherit the compatibility relations of their base types--a pointer to an extended record is regarded as an extension of a pointer to the base record. Assigning a pointer variable of an extended type to a pointer variable of the base type introduces the notion of "dynamic type."

The static type of a variable in Oberon is the type specified together with the declaration of the variable. The dynamic type of a variable is the type the variable assumes at run time. The dynamic type can only be an extension of the static type.

Consider, for example, two pointer variables v1: T1 and v: T, where T1 is an extension of T. If v1 holds a reference to a variable of type T1--that is, by a preceding NEW(v1)--the assignment v := v1 assigns a reference to a variable of an extended type to a variable of the base type. After the assignment, v's dynamic type is T1, the static type remains T. This rule also applies to passing extended records by reference (that is, as VAR-parameters). Only base-type fields can be accessed via v, but the extended fields of T1 still exist.

OOP based on message records and handlers seems, at first glance, rather inefficient and inconvenient. In practice, however, efficiency is not a big problem since a type test can be carried out in a constant, very short time (two loads plus one compare). It's also possible to speed up message identification by grouping messages, either using type extension or by introducing an explicit tag. Message forwarding is very efficient, and is independent of message-record size. Furthermore, specialized procedure variables can be introduced within an object to reduce the message-dispatching effort to the call of a procedure variable.

Event records are a similar technique used in contemporary operating or windowing systems. They are expressed by variant records (unions in C) that are not open ended and type safe. However, inefficiencies in the Macintosh or Windows operating system, for example, do not originate from the use of event records. Oberon's message records are "cultivated" event records.

The Oberon programming language has been developed together with an operating environment, the Oberon system. The language, however, makes very few assumptions about the environment. If not available from a given operating system, dynamic module loading, command invocation, and automatic garbage collection can be introduced by a small run-time system. In principle, it is possible to forego dynamic loading and to create traditional, statically linked applications, but this is anachronistic for the challenges of today's software systems. Automatic garbage collection is indispensable for reliable, extensible software systems and is probably the biggest culture clash between Oberon and other compiled languages such as Pascal, C, or C++.

Wirth N. and M. Reiser. Programming in Oberon: Steps Beyond Pascal and Modula-2. Reading, MA: Addison-Wesley, 1992.

MODULE M;
IMPORT M1, M2 := MyModule;

TYPE
  T* = RECORD
    f1*: INTEGER;
    f2: ARRAY 32 OF CHAR
  END ;

PROCEDURE P*(VAR p: T);
BEGIN
  M1.P(p.f1, p.f2)
END P;

END M.

WITH v: T1 DO
  v treated as being declared 
with static
  type T1 in this statement 
sequence
END

TYPE
  Object = POINTER TO ObjDesc;
  ObjDesc = RECORD ... END ;

  ObjMsg = RECORD END ;

  CopyMsg = RECORD(ObjMsg)
    deep: BOOLEAN; cpy: Object
  END ;

  ConsumeMsg = RECORD(ObjMsg)
    obj: Object; x, y: INTEGER
  END ;

PROCEDURE Handle (O: Object; VAR M: ObjMsg);
BEGIN
  IF M IS CopyMsg THEN handle copy message
  ELSIF M IS ... handle further message types
  ELSE ignore
  END
END Handle;

(a)
TYPE   Object = POINTER TO ObjDesc;
  ObjMsg = RECORD END ;
  Handler = PROCEDURE (O: Object; VAR M: 
ObjMsg);
  ObjDesc = RECORD
    handle: Handler
  END ;

(b)
TYPE
  MyObject = POINTER TO MyObjDesc;
  MyObjDesc = RECORD (Object)
    extended fields
  END ;

(c)
VAR o: MyObject;
NEW(o); o.handle := MyHandle;

(d)
VAR m: CopyMsg;
m.deep := TRUE; m.obj := NIL;
o.handle(o, m);

PROCEDURE MyHandle (O: Object; VAR M: ObjMsg);
BEGIN
  WITH O: MyObject DO
    IF M IS CopyMsg THEN handle copy message
    ELSIF M IS ... handle further message types
    ELSE Objects.Handle(O, M)
    END
  END
END MyHandle;

PROCEDURE Broadcast(VAR M: ObjMsg);
  VAR o: Object;
BEGIN o := firstObj;
  WHILE o _ NIL DO o.handle(o, M); o := nextObj END
END Broadcast;

Copyright © 1994, Dr. Dobb's Journal