Home Up Intro Contents Chapter 1 2 3 4 5 6 7 8 9 10 Design Assert Timing EBNF Report Pas Last Changed: Nov. 19, 1997
This is a conversion from Oberon text to HTML. 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 as ASCII-coded Oberon System 3 documents. 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 in German. Sorry if this is not one of your languages.

Einführung in die Programmiersprache Oberon.

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




03: Syntax und Semantik

Alle Komponenten von Oberon sind erlaubte Quellen für Kommandos. Es spielt keine Rolle, wo das Kommando eingegeben wird. Dies gibt beträchtliche Flexibilität, aber es ist auch eine denkbare Fehlerquelle. Anstelle eines Kommandos kann versehentlich irgend ein Text aktiviert werden. Oberon muss in der Lage sein, zumindest grobe Fehler und Probleme abzufangen. Was passiert, wenn Sie sich vertan haben und eine falsche Zeile/eine falsche Textstelle aktivieren ? Probieren Sie's ! Oberon kann gültige von ungültigen Kommandos auf zwei Arten unterscheiden.

  1. Syntaktische Analyse.

Es gibt eine eindeutig festgelegte Syntax, der alle Kommandos folgen. Wenn eine Eingabe nicht dieser Syntax folgt, dann kann sie kein Kommando sein.

  2. Semantische Analyse.

Wenn eine Eingabe syntaktisch akzeptabel ist, so legt die Syntax für die einzelnen Bestandteile bestimmte Rollen nahe. In einem zweiten Schritt kann Oberon prüfen, ob die Bestandteile eine Interpretation haben, die dieser Rolle gerecht werden kann. Um dies zu klären versucht Oberon, die Eingabe semantisch zu analysieren, das heisst die Bedeutung zu identifizieren.

Bei den meisten Teilen des obigen Text-Auszugs reicht die Syntax um zu entscheiden, dass dies keine Eingabe sein kann - Oberon kann sie als Kommandos ignorieren. Wenn Sie jedoch etwa auf das letzte Wort "identifizieren." gezeigt haben, so erhalten Sie im "System.Log" eine Meldung "not found". "identifizieren." ist als Eingabe syntaktisch zulässig. Erst die semantische Analyse zeigt Oberon, dass für "identifizieren." keine Bedeutung gefunden werden kann.

Aufgabe einer Programmiersprache ist es, syntaktische und semantische Regeln festzulegen, die eine eindeutige und effiziente Bearbeitung von Kommandos ermöglichen. Programmiersprachen sollen aber über die Verarbeitung vordefinierter Kommandos hinausgehen: wir wollen neue Kommandos definieren und Information zwischen verschiedenen Bearbeitungsschritten weiterreichen können. Konsistenz und Effizienz sind dabei oft gegenläufige Forderungen, die verschiedene Phasen der Bearbeitung betreffen: Die Analyse einer Eingabe und die konsistente Interpretation erfordert Zeit. Ist Verarbeitungsgeschwindigkeit massgeblich, so geht dies oft zu Lasten der Effizienz oder der Verlässlichkeit. Der Weg bei Oberon ist es, wie bei den meisten Systemen, bei Erweiterungen des Kommandovorrats die Analyse von der Ausführung zu trennen. In einem ersten Schritt wird die Beschreibung der Kommandoerweiterung, die Programmquelle, analysiert. Bei Inkonsistenzen oder unvollständigen Definitionen erfolgt eine Fehlermeldung und die weitere Bearbeitung wird abgebrochen. Bei konsistenter und hinreichend vollständiger Definition wird die Programmquelle von ihrer für den Menschen lesbaren Form in eine für die maschinelle Abarbeitung effizientere Form, das Programm-Objekt, umgewandelt. Dieser Prozess heisst Übersetzung (compiling). Die Programm-Quelle folgt dabei den Regeln der Oberon-Sprache; das übersetzte Programm wird dann vom Oberon-System genutzt. Bei Oberon, wie bei den meisten Programmiersprachen, muss die Übersetzung explizit angefordert werden. Nach der Übersetzung stehen die neuen Kommandos im Oberon-System für die Ausführung sofort zur Verfügung.

Die syntaktischen und semantischen Regeln der Sprache Oberon sind strenger als die einfachen Regeln, nach denen Kommandos identifiziert werden. Der grösste Teil des Kurses wird sich mit der Programmiersprache Oberon befassen. In diesem Kapitel beginnen wir mit den einfacheren Regeln der Kommando-Interpretation.

Ein Kommando ist die elementare Ausführungseinheit für das Oberon-System. Kommandos sind gebündelt in Modulen. Datenhaltung und konsistente Datenübergabe wird jeweils per Modul definiert. Ein Modul kann ausser extern zugänglichen Kommandos auch interne Prozeduren enthalten oder weitere extern zugängliche Prozeduren enthalten. Sichtbarkeit und Zugriffsbedingungen für Daten und Prozeduren festzulegen und zu überwachen sind Aufgaben der Module.

Ein Kommando rufen Sie auf, wenn Sie auf den Kommando-Name zeigen und "Aktivieren" drücken. So ist zum Beispiel
  System.Time
ein Kommando, mit dem die Zeit im System.Log notiert wird. Hingegen ist
  Dies ist kein Kommando
ohne Wirkung, während
  Fehler.
zu einer Fehlermeldung führt. Oberon kann diese Zeile durch eine syntaktische Analyse unterscheiden. Ein Oberon-Kommando hat immer die Syntax
  Modul-Name.Prozedur-Name

An diesem Beispiel wollen wir etwas genauer sein. Wir führen hier Konventionen und Darstellungsweisen ein, denen wir im weiteren folgen wollen. Wir benutzen hier eine typographische Konvention:
Stellvertreter werden wie abc dargestellt. Für sie werden nach Bedarf entsprechende Werte eingesetzt. Feste Eingaben haben das Aussehen abc. Sie müssen genau wie in der angegebenen Form geschrieben werden.

Modul-Name und Prozedur-Name sind syntaktisch gleichwertig. Beide haben einen gemeinsamen syntaktischen Typ, den wir Oberon-Name nennen.
Modul-Name:  Oberon-Name
Prozedur-Name:  Oberon-Name
Anstelle der gemeinsamen Bezeichnung Oberon-Name benutzen wir auskunftsfähige Namen, um die Intention einer syntaktischen Konstruktion deutlicher zu machen. Wir müssen für diese Verdeutlichung bezahlen: in einer zweiten Überlegung müssen wir unterscheiden, was syntaktische Definition ist, und was semantischer Hinweis.

Wir benutzen Ketten von Definitionen. Zur Definition dürfen nur Bestandteile benutzt werden, die eindeutig definiert sind. Oberon-Name ist noch nicht definiert. Was ist ein gültiger Name in Oberon ? Ist "Oberon" ein gültiger Name ? "Kommando für Oberon" ? "Pi" ? "3.14159" ? "a_b_c" ? "Jürgen" ? Sind griechische Namen (mit griechischen Zeichen) erlaubt ? Chinesische ? Es ist wichtig, strikte Regeln für Namen einzuführen. Dadurch können versehentliche Eingaben frühzeitig verlässlich identifiziert werden. Andererseits müssen alle Eingaben auf diese Regeln überprüft werden. Diese Überprüfung findet also an einer zentralen Stelle statt. Deshalb müssen die Regeln schnell überprüfbar, also einfach sein.
Hier ist der Oberon-Kompromiss: erlaubte Zeichen sind zunächst die Zeichen des US-ASCII-Codes. Buchstaben (im Sinne von Oberon) sind nur die Buchstaben in diesem Code, das heisst A-Z, a-z.
Buchstabe:  A-Z, a-z
Ziffer:  0-9
Erlaubte Namen sind alle Folgen von Buchstaben oder Ziffern, die mit einem Buchstaben beginnen. Um dies formal zu notieren benutzen wir eine Notation, die auf Backus und Naur zurückgeht.

xxx | yyy  bedeutet  xxx oder yyy
{ zzz }  bedeutet  keine, eine oder mehrere
     Wiederholungen von zzz
[ www ]  bedeutet  einen möglichen, aber nicht
      notwendigen Eintrag www.
Mit dieser Notation ist
Oberon-Name:  Buchstabe { Ziffer | Buchstabe }

Welche der folgenden Zeichenketten sind erlaubte Oberon-Namen:
  a) Oberon  b) Kommando für Oberon  c) Pi
  d) 3.14159   e) a_b_c     f) Jürgen
  g) Catch22  h) "Hallo"

Zusammengenommen bestimmen die folgenden Definitionen, was ein syntaktisch zulässiger Kommando-Name ist:
Buchstabe:  A-Z, a-z
Ziffer:  0-9
Oberon-Name:  Buchstabe { Ziffer | Buchstabe }
Modul-Name:  Oberon-Name
Prozedur-Name:  Oberon-Name
Kommando-Name:  Modul-Name.Prozedur-Name

Durch diese Syntax-Definition sind beliebig lange Kommando-Namen und Prozedur-Namen erlaubt. Auch hier muss zwischen Effektivität und Flexibilität abgewogen werden. Jedes konkrete Oberon-System setzt hier praktische Grenzen durch Implementierungs- Einschränkungen.

Ein Kommando kann nur ausgeführt werden, wenn es in syntaktisch zulässiger Weise aufgerufen wird. Damit es ausgeführt werden kann, muss es eine auswertbare Semantik haben. Der Modul-Name muss ein Modul bezeichnen, auf den Oberon zugreifen kann. Dieses Modul muss eine Prozedur mit der Bezeichnung Prozedur-Name zur Ausführung bereitstellen.

Wird ein Textausschnitt aktiviert, so führt Oberon eine syntaktische Analyse durch. Verwirft diese Analyse den Textausschnitt, so wird die Eingabe ignoriert. Ist die Eingabe syntaktisch zulässig, so versucht Oberon das entsprechenden Modul zu finden. Wird das Modul nicht gefunden, so durchsucht Oberon die für Oberon zugänglichen Dateien. Findet Oberon darin das entsprechende Modul, so wird es geladen. Andernfalls erfolgt eine Fehlermeldung, z.B. für das Kommando xxx.zzz die Meldung
  Call error: xxx not found
Konnte das Modul gefunden oder erfolgreich geladen werden, so sucht Oberon in diesem Modul die gewünschte Funktion. Wird sie nicht gefunden, so erfolgt eine Fehlermeldung
  Call error: zzz not found

Nicht jeder "sinnvolle" Name ist ein Name im Sinne der Oberon-Definition. Damit auch nicht-Oberon-Namen behandelt werden können, gibt es das Sprach-Konstrukt der Strings: ein String ist eine Zeichenkette (von darstellbaren Zeichen), die durch ' oder " abgegrenzt ist, und die diesen Delimiter nicht enthält. Damit ist es möglich, zum Beispiel Konstrukte wie
  "http://statlab.uni-heidelberg.de"
zu benutzen, ohne mit den Oberon-Konventionen in Konflikt zu geraten. Verschiedene Oberon-Implementierungen machen weitergehende Zugeständnisse, um ein bequemeres Arbeiten zu ermöglichen. So erlauben zum Beispiel die Oberon S3-Implementierung für Macintosh und Windows und die meisten UNIX-Implementierungen Dateinamen wie
  Kurs/Oberon2.EBNF
Die genauen Konventionen für Dateinamen hängen vom Umgebungssystem und der benutzten Oberon-Variante ab. Bitte informieren Sie sich in den Unterlagen zu Ihrem Oberon-System.

Die vollständige Syntax von Oberon füllt weniger als eine Seite. Sie erhalten diese Tabelle, wenn Sie
  Desktops.OpenDoc Kurs/Oberon2.EBNF
aktivieren. Dies ist ein Auszug aus dem Oberon-Report, der Syntax und Semantik von Oberon definiert. Der Oberon-Report ist die grundlegende Definition der Sprache Oberon. Den Oberon-Report erhalten Sie mit
  Desktops.OpenDoc Kurs/Oberon2.Report.Text

Einführung in die Programmiersprache Oberon. Kurs/Kap03.Text
gs (c) G. Sawitzki, StatLab Heidelberg
<http://statlab.uni-heidelberg.de/projects/oberon/kurs/>

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