Home Up Intro Contents Chapter 1 2 3 4 5 6 7 8 9 10 Design Assert Timing EBNF Report Pas 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 ftp.
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

G. Sawitzki <gs@statlab.uni-heidelberg.de>



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 diagnostics
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
  System.ShowModules
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
  System.Directory *.Obj

A first information about the modules is the list their commands. If the name of a module is selected, these commands are extracted
  System.ShowCommands ^ ,
Or we can add the name of a module, as in
  System.ShowCommands Oberon
One slightly more detailed picture is given by listing all exported information items. This list is generated with the command
  Browser.ShowDef ^
or, e.g.
  Browser.ShowDef Oberon

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
  Call error: 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
  Call error: 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 back.
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 position.


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
  Browser.ShowDef Files
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
  Browser.ShowDef Display
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: ==>
DEFINITION Display;

  IMPORT
    Objects, Files;
  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.

  TYPE  data 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 other modules.
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
  System.State Modul
for examples
  System.State Display

  Basic display procedures.

END Display.


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 reference implementation.

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 beside it.

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
  Desktops.OpenDoc ItO/PIO/In.Mod
  Desktops.OpenDoc ItO/PIO/Out.Mod
  Desktops.OpenDoc ItO/PIO/xyPlane.Mod
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 example
  Browser.ShowDef In

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 by In.Mod.

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
  Browser.ShowDef xyPlane
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
  ItO/PIO/RandomNumbers.Mod  ItO/PIO/IFS.Mod ~

IFS.Draw can be interrupted by pressing any key. Start it using
  IFS.Draw

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
<http://statlab.uni-heidelberg.de/projects/oberon/intro/>

Home Up Intro Contents Chapter 1 2 3 4 5 6 7 8 9 10 Design Assert Timing EBNF Report Pas