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
10 The Oberon Run Time System
In Oberon, programs (or more exactly modules) can call upon services of other
modules, for example services of these modules:
System system information and control
Texts base of the text processing
Builder compiler surface and error
Compiler compiler for Oberon programs
We will study the text handling as an example. So far, we did not go into
details of input and output. Input and output are not part of the language,
but are services, which are furnished by procedures. For these procedures,
the usual rules of the Oberon language apply. There are no exceptions for
input and output. In the reference implementation of the Oberon system, the
fundamental procedures for text input and output are located in module Texts.
Oberon is modular and extensible. Therefore the Oberon system can be adapted
and augmented to give additional services, or access to certain services
can be restricted, or the way in which services are provided can be changed.
The current scope of a system cannot be described statically, but only determined
dynamically, for example using services of module System - The reference
model of the Oberon system can help orientation. Its procedures and use are
described in Reiser (1993). Design and implemetation, and thus the entire
internal structure, are documented in Wirth and Gutknecht (1992). However
the reference model can only be an orientation - current specific implementations
will have differences.
Oberon is a progress in computer science. Comfortable prejudices and simplifications
must be thrown over board, if you go on this journey. Not for the first time
one must free oneself from ballast. Early beginnings in computer science
permitted essentially only sequential programs, with (conditional) branches
as only exception. The comfortable linear structure, in which thinking could
prod here, was broken with programming languages such as ALGOL. Programs
would be regarded as structured, as a large control structure with blocks
(or modules) as items. The prevailing view was still one main program, consisting
of a hierarchy of subroutines. The typical structure was a tree (although
ALGOL already permitted recursions). A tree is a simpler structure than a
general graph, but there is no necessity to be limited to the simple structure
of a tree. In Oberon this tree structure is not any longer presupposed.
Oberon should be regarded as general graph. Depending upon the view one will
be able to detect trees in this graph. There is not however the uniquely
singled out root of the tree, as there was at the times of the "main program".
Whenever an analysis of the Oberon system is taken, a certain focus has to
be taken. This focus usually determines which module can serve as a starting
point for the analysis.
One receives an overview of the current system with
In this outline only the active modules are contained. Besides these, there
are modules, which have been successfully compiled and are available, but
are not yet loaded. Conventionally these modules are stored in files with
the name ending Obj. A list of these files is generated using
A first information about the modules is the list their commands. If the
name of a module is selected, these commands are extracted
Or we can add the name of a module, as in
One slightly more detailed picture is given by listing all exported information
items. This list is generated with the command
The next step is to step into the hierarchy of imported module, using Browser.ShowDef
^ on the modules shown in the import list.
In this diagram Files and Display appear as end points. They
do not import lower level modules.
In an extensible modular system, consistency is not guaranteed automatically.
One cannot assume a uniformly installed system without modifications. Therefore
checks for sufficient consistency of the system have to be performed at run
time. This happens in Oberon whenever a module is loaded. The check proceeds
in two steps have. First it is checked whether the called module is available
as file and whether this file actually contains a module. If an error occurs,
a typical error message is
xxxx not found
If the module is found, it is checked whether the exported information of
the module corresponds to the declarations which the calling module expects.
If an error occurs, a typical error message is
yyyy imports xxxxx with bad key
Using in- or output as an example, we examine now the interaction of different
modules. "Files" is the module which supports basic types for the storage
of data, in particular the type Files.File. Each
computer system needs a possibility of storing data safely for longer time
and of recovering stored data. In Oberon, this functionality is assigned
to the module Files. The basic data structure, represented by the type Files.File,
i is a finite sequence of bytes. To make flexible use of this model, other
data structures have to be translated into a sequential byte structure and
A file in Oberon for a start is but a sequence of bytes, with a well defined
length. Access is sequentially using a Rider. This
is a data structure for managing access, for example noting the current access
More than one rider can refeer to the same file. This allows to work on different
positions of the file while keeping full synchronicity.
To get a survey of the implementation of Files on you system, use
Files contains a small group of procedures for file management and
to relate riders to file, and a whole collection of read and write procedures.
Its basic model is for it not a sequence of bytes (as in Files), but a two-dimensional
raster, in which points can be marked using different attributes. This is
the basic model which is built upon for writing text, as well as for showing
patterns and graphics.
To get a survey of your implementation of Display, use
Module Display can serve to illustrate several typical techniques
of programming in Oberon. The sample code included here is taken from the
Macintosh implementation of Oberon System3. You can follow the discussion
step by step. The discussion is divided into sections, marked with . These
marks can be activated the ususal way and will show additional information,
or swap to a more condensed representation.
Aktiviate this mark: ==>
CONST definition of numeric constants
for symbolic names. Unfortunately Oberon does not permit purely symbolic
constants. With the trick to introduce numeric constants for symbolic names
at least a homogeneous way of writing can be achieved.
types. Building upon basic data types, new data types can be defined. Variables
are always bound to data types by their declaration. Thus it is possible
for the compiler to examine the type compatibility and to detect violations
already during the development phase of a program.
This check of the type compatibility is done also for the parameters of procedures.
Data types give a basis for communication. Since in Oberon types can be extended,
it is also possible to write generic procedures which support a whole family
of types as parameters.
Control over the visibility of types and the details of type declarations
is in the authority of the programmer. The programmer determines which types
or which type details are exported. It is possible to define abstract types.
An abstract type is a type exporting no implementation details. This is a
way to guarantee that internal changes of the implementation can never disturb
If access to components of an abstract type should occur from the outside,
access procedures must be supplied for this purpose.
VAR Variable declarations. Memory
space is supplied by the variable declarations for the variables. Each variable
is bound to a type by the declaration. Release of variables, and thus memory
deallocation, is administered automatically by Oberon. The current status
of a module is defined by the values of the variables. The visible part of
this status is reported by
Basic display procedures.
Commented definition of module Display
The modules display and files are supplied in the Oberon system for the support
of input and output. Input and output are notorious problem areas with all
programming languages. A programming language is needs to open possibilities
of describing procedures abstractly. Input and output however must always
refer to concrete implementations. Between language and implementation, there
is a field of tension. So far, there are no generally accepted ultimate solutions
to resolve this tension. Therefore input and output are not taken up as constituents
of the language Oberon language. However each implementation
of Oberon will support these functions. A model implementation is described
in "Project Oberon" (Wirth & Gutknecht, 1992). This is the general reference
implementation, and most implementations can be describe in the reference
to "Project Oberon". Both modules, Files and Display, are documented in this
The model implementation shows one possibility of controlling input and output.
The model implementation heads for a model which is as universal as possible,
but still allows for an efficient implementation. Other possibilities exist
We look at one example. In Reiser&Wirth (1992), models are indicated,
which are particularly simple as a concept. To open the implementation sources
of these models, use
In some Oberon implementations, these modules are included in the
distribution. If they are missing, compile them now. As usual after compilation
we can extract information about the exported interfaces directed using for
The implementation of In.Mod shows Oberon standard technique to access external
information. We already know that each parameterless procedure, which is
exported, can be called as command. Non-exported procedures are outward not
visible outside of the defining module. Exported procedures with parameters
can be called from other modules, but cannot be called as commands. In order
to supply with further parameters to commands nevertheless , the module Oberon
provides information about the system state. The procedure In.Open accesses
first the input following immediately after the command. Oberon.Par.text
and Oberon.Par.pos indicate where this information
can be found. In.Open also decodes whether this information is a reference
according to the Oberon conventions. If an arrow or an asterisk follows,
then the input is looked up elsewhere: an arrow refers to the last current
text section. This Selection is to be found using the procedure Oberon.GetSelection.
An asterisk refers to the marked viewer. Oberon.MarkedViewer
supplies the appropriate viewer. If neither of these special symbols follows,
the input begins immediately after the command. This decoding is hidden in
the procedure In.Open. Now if any command begins its execution with the call
of the procedure In.Open, then the input is prepared according to the Oberon
conventions and further input can be read unsing the procedures supplied
For the text output we have already seen the procedures in module Texts.
For graphic output the primitive items are supplied in Display. Usually one
makes use of procedures, which cover a set of conventions, for example those
exported xyPlane.Mod. These are listed using
The constants draw and erase
are pre-defined values for the formal parameter mode in the procedure Dot.
Position and size of the drawing area are noted in H, w, x, y. These values
are only defined after the procedure open is called. Open initializes a drawing
area which covers the entire user track. Draw marks or deletes one point
at the position x,y. IsDot returns the status of one point. Key monitors
the keyboard. If a key was pressed, then Key returns the appropriate character
value. If no key was pressed, then a character with the value 0X is returned.
Clear erases the drawing area.
Examine the text xyPlane.Mod. Which procedures can you
interpret completely with the information you have so far? Mark these procedures,
and give a complete description of their function. For which procedures can
you make an informed guess with some confidentiality? Write down how you
would check your guesses. Which language elements and constructions are still
unknown to you? Mark these.
Compile the modules
IFS.Draw can be interrupted by pressing any key.
Start it using
We reached the end of a first passage through the Oberon language.
The second passage looks at some aspect in more details, using case studies.
A third passage is a walk through the formal definition of Oberon, which
is the basis for practical work.
Introduction to the Oberon programming language. ItO/Ch10.Text
gs (c) G. Sawitzki, StatLab Heidelberg