Oberon-ItO Ch04 Module Structure

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>

04 Module Structure, Compiler and Loader; System State

You can open an example of a complete Oberon program using
   Desktops.OpenDoc ItO/ItOProg01.Mod ~
Before using this program it needs to be compiled. Open the file Builder.Tool using Desktops.OpenDoc Builder.Tool ~ Mark the viewer of ItOProg01.Mod and activate Builder.Compile * \s from the Builder.Tool. This corresponds to the command
  Builder.Compile ItO/ItOProg01.Mod \s ~
** If the Heidelberg tools are available to you, please use gsBuilder instead of Builder for the rest of this course **
After compiling, a report message in the System.Log appears.
With
  ItOProg01.Test
the program is started. It writes a time stamp to the System.Log; a new viewer named "System.ShowModules" is opened in the system track, and a list of the currently loaded modules appears. Repeating the command.
  ItOProg01.Test
gives an additional viewer named "System.ShowModules" and a list of the currently loaded modules.

Remark: in the first versions of this Oberon system you would use
  Compiler.Compile * \s ~
Builder.Compile has additional features, making management of module groups much easier. If no errors occurred, both commands have equivalent results for individual files. If errors occur, these are listed in the System.Log. If the error list is selected, Builder.MarkErrors ^ adds error marks in the marked program source. If you use gsBuilder, the error marks automatic are inserted automatically.

A table of error codes and their explanation can be found in file OberonErrors.Text. More information about the compiler and options to control it are given in file Compiler.Tool.

Remark: in older programming languages it was necessary to link a program/module with library programs after compilation. This step is not needed in Oberon.

The compilation unit is a module. Usually each module is stored as a separate text file. The term "program" used above is actually not appropriate for Oberon. In older systems, "program" was used for a separately compilable unit which was closed and contained executable code. In the Oberon system there are no closed units: the Oberon units, called "modules", can always cooperate. In principle, each module can communicate with any other module. The module "ItOProg01" for example communicates with module "System" and uses commands ShowModules and Time defined in "System".
Communication and access possibilities however follow a certain protocol. The basic rule is that each communication and access possibility has to be permitted explicitly. Without permission, no access is possible. In each module objects (types, variables, procedures) can be defined. Each object has a name which identifies it uniqely within the defining module. If access to an object should be permitted, the object has to be exported. An object is marked as exported, if the name definition has a star (*) following next to the name. For example in ItOProg01.Mod, procedure Test is defined and exported. Therefore it is possible to call it using the command ItOProg01.Test. If the name is followed by a minus (-), the information of that object can be read from modules other than the defining module, but it cannot be changed. The "read only" export gives some protection against unintended changes.

Syntax of a name declaration:
  Oberon name [*|-]

Exported objects can be used in other modules. A modification of the implementation of an exported object can hence have far reaching consequences. This can be intended, for example if the modification improves the functionality. But it can also invalidate other modules, for example if condition for calling a procedure have changed. As a safeguard against unintended modifications, changes of the export structure must be explicitly advertised upon compilation. This is done using an option \s for the compilation command. Without this option, the compiler will not generate new code if the export structure has changed. If this option is used, no additional safeguards are given and the programmer proceeds at own risk. An example for the use of this option is
  Builder.Compile * \s
or
  Builder.Compile ItO/ItOProg01.Mod \s ~

Procedure syntax:
  PROCEDURE [*] [target] procedure name
      [formal parameters];
    deklaration sequence
  [BEGIN
    statement sequence  ]
  END procedure name;

We will come back to details of this definition later. In our example the definition of the procedure Test is particularly simple: most components are void, the statement sequence consists only of a single statement, a call of System.Modules.

The complete module has the structure
Module syntax:
  MODULE module name;
    [import list]
    declaration sequence
  [BEGIN
    statement sequence ]
  END module name.

The module name is an identifikation, used to access the module. The import list gives the name of all module the service of which is accessed by out module. In our example, the module System is imported.

Import list:
  IMPORT
    [name := ] module name { , [name := ] module name } ;

The optional names in the import list are used to introduce "alias names", like abbreviation and temporary name changes. For example using the import list
  IMPORT sys:=System;
the module System can be accessed using the name sys. So the Time command would be called using sys.Time in a module using this import list.
The declaration sequence contains declarations of types, variables and procedures. The statement sequence contains those statements that are to be executed when the module is loaded. In our example the statement list consist only of the statement System.Time.
In Oberon, a module is loaded whenever access to one of its elements is first requested. A module stays loaded until Oberon is rebooted, or until the module is unloaded explicitly using the command
  System.Free modul name
That is why the statement sequence in our example is only executed at the first activation of ItOProg01.Test. The time stamp is only set once in System.Log. If you interclick "position" while activating a command, the corresponding module is forced to re-load. This is a helpful short cut to reload modules which are still under development.

The statement sequences in our example are simple so far and consist of just one statement. The general syntax is
Statement sequence:
  statement {; statement}

Modules and procedures haben a similar syntax. A module is in a sense the "packing unit" in Oberon, a procedure is the executable unit. Several procedures can be bundled into one module. Besides exported procedures a module can contain procedures which are intended only for the internal usage within this module. Modules are always visible from the outside, procedures are only visible if they are explicitly marked as exported.
The statement sequence of a module is executed only once when the module is loaded. The information of a module is preserved as long as the module is loaded.
The statement sequence of a procedure is executed each time the procedure is called. Internal information of a procedure is lost as soon as the procedure is completed.

Exercises:

Release module ItOProg01 using
  System.Free ItOProg01 ~
Prepare a copy of ItOProg01.Mod using
  System.CopyFiles ItO/ItOProg01.Mod => ItO/ItOTest01.Mod
Open the copy using
  Desktops.OpenDoc ItO/ItOTest01.Mod ~
Change the statement in procedure Test a real statement sequence by replacing
  System.ShowModules
by
  System.ShowModules;
  System.Time
Save the modified file using Desktops.StoreDoc (Menu bar!). Compile it using
  Builder.Compile ItO/ItOTest01.Mod \s ~
Activate it repeatedly using
  ItOTest01.Test

In Oberon, a loaded module in extends the system. Its services are avaible in the same way all system services are available. This way, the Oberon system can change dynamically.

Besides the language report which is defining the basis of the language, we need tools, to determine the dynamic contents of the Oberon. Module System has commands to inspect the system state. With
  System.ShowModules
you get a list of all currently loaded modules.
  System.ShowCommands module name
gives a list of all commands in a module, that is all parameterless exported procedures. In particular, for the module System itself, you can use
  System.ShowCommands System
The current values of the variables of a loaded module are shown by
  System.State module name
For example
  System.State System

For the programmer, the module Browser is an additional tool.
  Browser.ShowDef module name
gives a complete reconstruction of all exported objects in a module, for example
  Browser.ShowDef System
While the System commands show the dynamic state of the current modules, the Browser gives static definitions as defined at compilation time, but in general this information is shown in more detail than the System information.

In Oberon System 3 provides Watson as an integrated tool
  Watson.ShowDef modul  name
gives complete information about a module as hypertext, for example
  Watson.ShowDef System
In contrast to System and Browser which access the module itself, Watson tries different paths to collect the information. The user has control over the access paths to be tried. If the information found first in any of these paths is reliable, Watson can give the most complete information.

Exercises:
Use
  System.ShowCommands System
  System.State System
  Browser.ShowDef System
  Watson.ShowDef System
to collect information about module System and compare the information.

Use
  System.ShowCommands Math
  System.State Math
  Browser.ShowDef Math
  Watson.ShowDef Math
to collect information about module Math and compare the information.

The individual commands of the module System are documented in
N. Wirth, J. Gutknecht: Project Oberon. Addison Wesley 1992

Introduction to the Oberon programming language. ItO/Ch04.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