Oberon-ItO Ch03 Syntax&Semantic

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>

03: Syntax and Semantics

All components of Oberon are legal sources for commands. It does not matter where a command is entered. This adds considerable flexibility, but it is also a potential source of errors. Instead of activating a command some arbitrary text could be activated accidently. Oberon has to be able to prevent at least gross errors and problems. What happens, if you activate a wrong line or a wrong text selection? Do some experiments! Oberon has two means to tell valid from invalid commands.

  1. Syntactical analysis.

There is a unique syntax, followed by all commands. If an input does not adhere to this syntax, it cannot represent a command.

  2. Semantic analysis.

If an input is syntactically acceptable, the syntax suggests certain roles for the individual components. In a second step Oberon can check whether the components have an interpretation which may fit to these roles. To check this Oberon tries to analyse the input semantics, that is to identify the meaning.

For most parts of the text section above, a mere syntactical analysis is sufficient to find out that it cannot possibly be a command input. Oberon can safely ignore all attempts to use these sections as commands. However if you have tried to activate the last word "meaning.", you get a messsage "not found" showing up in the System.Log viewer. "meaning." has an admissible syntax to be a candidate for a command. Only using a semantic analysis tells Oberon that "meaning." cannot be used as a command.

It is up to a programming language to specify syntactical and semantic rules that allow efficient and well defined processing of commands. But programming languages have to go beyond processing of pre-defined commands: we want to be able to define new commands and to pass information reliably between different processing steps in an efficient way. Reliability and efficiency are often competing requirements, usually focussing on different processing phases. Analysis of an input and consistent iterpretation needs time. If processing speed is the most important aspect, increased speed often may be gained at the risk of losing reliability. Like with most programming languages, Oberon separates the analysis of the input specifying command extensions from the command execution. In a first step the program source, the description of the command extension, is analyzed. If inconsistencies or incomplete definitions are detected, error messages are emitted and and the additional processing is aborted sooner. If the program source proves consistent and is sufficiently complete, the program source is translated from its human readable form to a program object, a form which is more efficient for machine processing. This process is called compilation. The input to compilation has to satisfy the rules of the Oberon programming language. The output form has a structure which is private to the Oberon system. As for most programming languages, compilation must be explicitly started for Oberon. After compilation the new commands are immediately available for execution in Oberon. Unlike in other systems, there is no separation between "built-in" commands and user generated commands. And, again unlike in other systems, no separate "linking" or additional preparations are needed in Oberon.

The syntactical and semantic rules of the Oberon language are much stricter than the simple rules by which commands are identified. For most of this course we concentrate on the rules of the Oberon language. In this chapter we start with the simpler rules for command interpretation.

A command is the elementary execution unit for Oberon. Commands are bundled in modules. Data management and consistent data access is defined by module. Besides commands which can be accessed externally, a modul can contain internal procdures or additional procedures that allow external access. The module is responsible for determining and monitoring visibility and access conditions for data and procedures.

To call a command, point to the command name and press "activate". For example, this is a command which writes a time stamp to the System.Log:
  System.Time
On the other hand,
  This is no command
has no efffect when activated, while
  Error.
leads to an error message. Oberon can distinguish between these lines by a syntactical analysis. An Oberon command has always the syntax
  module name.procedure name

We have a closer look at this example. We are introducing conventions and representations here which we will follow for the rest of this course. The typographical conventions we are using are:
Placeholders are shown like abc. For a placeholder you have to substitute corresponding values as the context may require. Fixed input is shown like abc. You have to enter fixed input in exactly the same form as given.

Module names and procedure names have the same syntactical form. Introducing a syntactical type which we will call Oberon name, we have:
Module name:  Oberon name
Procedure name:  Oberon name
Instead of using the common name Oberon name use we use the more specific names if we want to point out the intention of the syntactical construction. Of course if we use this separation, we always have to look closely to see whether we have a syntactical definition, or only a semantic hint.

We are going to use chains of definitions. In the defining part of a definition, we may use only components that are well defined. Oberon name is not yet defined. What is a valid name in Oberon? Is "Oberon" a valid name? "Command for Oberon"? "Pi"? "3.14159"? "a_b_c"? "Jürgen"? Are greek names (using greek characters) permitted? Chinese? It is necessary to introduce strict rules for names. This gives a way to detect some erroneous input reliably at a very early state. On the other hand, all input has to be checked to satisfy these rules. So checking for naming conventions takes place at a central position. This recommends using rules which allow rapid checking, hence simple rules should be preferred.
Here is the compromize taken in Oberon: valid characters for a start are the character of this US ASCII code. Letters (i.e. permitted letters for the formation of Oberon names) are only the letters in this code, that is the letters A...Z, a...z.
Letter:  A...Z, a...z
Digit:  0...9
Accepted names are all sequences of letters or digits, starting with a letter. To write this in a formal way, we use we a notation going back to Backus and Naur.

xxx | yyy  means  xxx or yyy
{ zzz }  means  no, a or several
     repetitions of zzz
[ www ]  means  possibly one, but not
      necessarily one entry www.
Using this notation, we have
Oberon name:  Letter { Digit | Letter }

Which of the following character sequence are accepted Oberon names:
  a) Oberon  b) command for Oberon  c) Pi
  d) 3.14159   e) a_b_c     f) Jürgen
  g) Catch22  h) "Hallo"

Together these definitions specify what is a syntactically correct command name:
Letter:  A...Z, a...z
Digit:  0...9
Oberon name:  Letter { Digit | Letter }
Module name:  Oberon name
Procedure name:  Oberon name
Command name:  Module name.Procedur name

This syntax definition allows command names and procedure names of arbitrary length. Again a choice has to be taken, weighting effectivity against generality. Each implementation of an Oberon system imposes practical limits, which may vary from implementation to implementation.

A command can only be executed, if it is called in a syntactically accepted way. To actually execute a command, the call must lead to a semantic reference which can be evaluated: the module name must correspond to a module which is accessible to Oberon. This module must provide a procedure with an identifier corresponding to procedure name for execution.

If a text segment is activated, Oberon does a syntactical analysis. If this analysis rejects the text segment, the input is ignored. If the input passes the syntactical test, Oberon tries to find the corresponding module. If the module is not found, Oberon searches the files accessible to Oberon. If Oberon finds the corresponding module during this file search, the module is loaded, else an error message is emitted. For example the command xxx.zzz would give the message
  Call error: xxx not found
If the module is found, or if it could be loaded successfully, Oberon searches this module for the procedure requested. If it is not found, an error message is emitted:
  Call error: zzz not found
If all succeeded, the procedure is called to perform the service requested.

Not all names which are meaningful for a user give names in the sense of the Oberon definition. To allow handling of non-Oberon names, the Oberon language has a language construct named strings. A string is a sequence of characters (with a visible representation), enclosed by ' or ", and not containing these delimiters. Using this, it is possible to use strings like for example
  "http://StatLab.uni-heidelberg.de"
without getting conflict into with the Oberon conventions. Various Oberon implementations allow for more, to permit easier work. For example the Oberon S3 implementations for Macintosh and Windows and most UNIX implementations allow file names such as
  ItO/Oberon2.EBNF
The detailled conventions may depend on the run time environment you are using. Please consult the documentation for your Oberon system.

The complete syntax of Oberon barely fills a page. You get this table, if you activate
  Desktops.OpenDoc ItO/Oberon2.EBNF
This is an excerpt from the Oberon Report which defines the syntax and semantic of the Oberon language. The Oberon Report is the authentic definition of the language Oberon. The Oberon Report can be accessed using
  Desktops.OpenDoc ItO/Oberon2.Report.Text

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