imported>Thomas Dresler: Klammern korrigiert

2025-12-20T14:46:52Z

Klammern korrigiert

Neue Seite

{{Infobox Programmiersprache
|Name =
|Paradigma = [[Imperative Programmierung|imperativ]], [[Strukturierte Programmierung|strukturiert]], [[Modul (Software)|modular]]
|Erscheinungsjahr = 1978
|Entwickler = [[Niklaus Wirth]]
|Typisierung =
|Implementierung =
|Dialekte =
|Beeinflusst_von = [[Pascal (Programmiersprache)|Pascal]]
|Beeinflusste = [[Lua]], [[Oberon (Programmiersprache)|Oberon]], [[Seed7]], [[Modula-2+]], [[Modula-3]]
}}

'''Modula-2''' ist eine 1978 entstandene Weiterentwicklung der [[Programmiersprache]] [[Pascal (Programmiersprache)|Pascal]] und wurde wie diese von [[Niklaus Wirth]] entwickelt. Hauptkennzeichen von Modula-2 sind die Sprachmerkmale zur [[Modul (Software)|Modularisierung]] von Programmen. Modula-2 selbst diente später als Vorlage für die Programmiersprache [[Oberon (Programmiersprache)|Oberon]].

== Entstehung ==
Wirth hatte 1977/78 am Forschungszentrum Palo Alto Research Institute von [[Xerox PARC|Xerox]] die zukunftsweisende Architektur der [[Xerox Alto|Alto]]-Workstations kennengelernt, die bereits über Maus, Grafikbildschirm und Fenstertechnik verfügten. Programmiert wurde der Alto in der Pascal-ähnlichen Programmiersprache [[Mesa (Programmiersprache)|Mesa]]. Nach seiner Rückkehr an die [[Eidgenössische Technische Hochschule Zürich|ETH Zürich]] begann Wirth mit seiner Gruppe die Eigenentwicklung einer solchen Workstation, der später so genannten [[Lilith (Computersystem)|Lilith]], wobei Hardware und Software im Zusammenhang entwickelt wurden.

Standard-Pascal, das als Sprache für den Programmierunterricht entwickelt worden war, eignete sich nicht für die Programmierung eines [[Betriebssystem]]s für die Lilith, und zwar vor allem aus zwei Gründen:

* es fehlen Vorrichtungen für die [[Nebenläufigkeit|nebenläufige Programmierung]]
* die Aufteilung eines großen Programms in zahlreiche Module mit sauber definierten [[Schnittstelle#Softwareschnittstelle|Schnittstellen]] nach den Lehren der [[Softwaretechnik]] ist nicht möglich.

Die neue Sprache, die den Namen „Modula“ erhielt, enthielt gegenüber Pascal deshalb (neben etlichen Änderungen in der [[Syntax]]) zwei neue Konzepte:

* Prozeduren <code>NEWPROCESS</code>, <code>TRANSFER</code> und <code>IOTRANSFER</code> zur Behandlung nebenläufiger Prozesse ([[Thread (Informatik)|threads]]) im Sinne eines [[Kooperatives Multitasking|kooperativen Multitaskings]] und
* das <code>MODULE</code> als Einheit für die separate [[Compiler|Übersetzung]] von Programmteilen.

Modula wurde außerhalb der [[ETHZ]] erst in der Version Modula-2 bekannt.
Die klare Trennung von Definition und Implementierung in getrennten Dateien (in der Regel mit [[Dateiendung|Extension]] DEF bzw. MOD) war richtungsweisend und wurde von späteren Programmiersprachen zwar kopiert, aber in ihrer Klarheit nicht erreicht.
Modula-2 hatte später von Wirth unabhängige Nachfolger wie [[Modula-2+|Modula-2 plus]] und [[Modula-3]]. Seit 1996 gibt es eine internationale Norm [[ISO]]/[[International Electrotechnical Commission|IEC]] 10514-1 für Modula-2.

== Eigenschaften ==
Da Modula-2 eine Fortentwicklung von [[Pascal (Programmiersprache)|Pascal]] ist, genügt es, auf die wesentlichen Unterschiede zu dieser Sprache einzugehen.
=== Module ===
Die prominenteste Neuerung in Modula-2 sind die ''Module'' als Vorrichtung für das modulare Programmieren nach den Vorstellungen der [[Softwaretechnik]], zuerst geäußert von [[David Parnas]]. Auch das Hauptprogramm heißt deswegen <code>MODULE</code> statt <code>PROGRAM</code> wie in Pascal. Alle separat vom Hauptprogramm übersetzten Teile müssen in zwei Dateien aufgespaltet werden: Ein <code>DEFINITION MODULE</code> enthält nur die Beschreibung der [[Schnittstelle]] des Moduls, das heißt: es listet die Konstanten, Typen, Variablen und Prozeduren auf, die für andere Module zur Verfügung gestellt („exportiert“) werden sollen. Ein getrenntes <code>IMPLEMENTATION MODULE</code> gibt dann die Implementierung an.

Es ist im Sinne der strikten [[Modularisierung]] folgerichtig, dass Konzepte wie die [[Eingabe und Ausgabe|Ein-/Ausgabe]] und mathematische Funktionen, die in Pascal zum normalen Sprachumfang gehörten, in der Sprache Modula-2 nicht enthalten sind. Sie müssen im Bedarfsfall aus dafür vorgesehenen Modulen (in der Regel <code>InOut</code> für Ein-/Ausgabe und <code>MathLib</code> für die mathematischen Funktionen) importiert werden.

=== Datentypen ===
Die Lilith sollte eine Wortbreite von 16 bit bekommen. Ganze Zahlen hätten somit einen Bereich von -32.768 bis +32.767 gehabt, was Wirth als zu große Einschränkung empfand. Zusätzlich zum Datentyp <code>INTEGER</code> bekam Modula-2 daher einen Datentyp <code>CARDINAL</code> für die nicht-negativen Zahlen zwischen 0 und 65.535. Gemischte Ausdrücke, die sowohl <code>INTEGER</code>- als auch <code>CARDINAL</code>-Teilausdrücke enthalten, waren verboten. Deshalb gibt es allgemeine Möglichkeiten, Typen zu verwandeln:

* Typ''konversions''funktionen <code>VAL(</code>''Typ'',''Ausdruck''<code>)</code> rechnen einen Ausdruck so um, dass er zu dem neuen Typ gehört, während
* Typ''transfer''funktionen („''type casts''“, bei Wirth: „''type cheats''“) der Form ''Typ''<code>(</code>''Ausdruck''<code>)</code> ein Bitmuster unverändert lassen und lediglich für den Compiler den Datentyp verändern.

Beispielsweise ergibt <code>VAL(CARDINAL,-1)</code> eine Fehlermeldung, während <code>CARDINAL(-1) = 65.535</code> gilt.

Eine Innovation gegenüber Pascal stellt auch der Datentyp <code>PROCEDURE</code> dar, mit dem eine Schwäche von Pascal behoben werden sollte: In Pascal war es möglich, einer [[Prozedur (Programmierung)|Prozedur]] eine [[Funktion (Programmierung)|Funktion]] als Argument zu übergeben, gekennzeichnet durch das Schlüsselwort <code>FUNCTION</code>. Dabei konnte jedoch nicht überprüft werden, ob die später aktuell übergebene Funktion in Anzahl und Typ ihrer Parameter überhaupt passend war. Deklariert man jedoch in Modula-2 beispielshalber
<syntaxhighlight lang="modula2">
TYPE myFunction = PROCEDURE (INTEGER): REAL;
</syntaxhighlight>
so kann beim Aufruf einer Prozedur (das Schlüsselwort <code>FUNCTION</code> gibt es in Modula-2 nicht)
<syntaxhighlight lang="modula2">
PROCEDURE myProcedure (f: myFunction; n: INTEGER): REAL;
</syntaxhighlight>
der Compiler bei jedem Aufruf von <code>myProcedure</code> feststellen, ob die aktuell für <code>f</code> übergebene Funktion den richtigen Typ hat. Da Prozeduren damit ganz normale Datentypen sind, ist es auch möglich, sie in anderen Datenstrukturen wie etwa <code>ARRAY</code>s und <code>RECORD</code>s einzubauen.

=== Kontrollstrukturen ===
Zur Vermeidung zahlreicher <code>BEGIN</code> − <code>END</code>-Klammern wird in Modula-2 die <code>IF</code>- und <code>WHILE</code>-Anweisung jeweils mit einem <code>END</code> abgeschlossen. Das von Pascal vertraute <code>GOTO</code> gibt es nicht, dafür aber ein <code>LOOP</code> – <code>EXIT</code>-Konstrukt.

=== Das Pseudomodul SYSTEM ===
Als Sprache für die Betriebssystemprogrammierung musste Modula-2 über Vorrichtungen verfügen, auf Details der zugrundeliegenden Maschine zuzugreifen. Dafür gab es ein eigenes Modul <code>SYSTEM</code>, aus dem sich die Datentypen <code>WORD</code> für ein unspezifisches Speicherwort und <code>ADDRESS</code> für eine Speicheradresse importieren ließen, ebenso wie eine Funktion <code>ADR</code> zur Ermittlung der Speicheradresse eines Konstrukts und <code>TSIZE</code> zur Ermittlung der Speichergröße für einen bestimmten Datentyp. Hinzu kommen die bereits erwähnten Funktionen für die nebenläufige Programmierung.

<code>SYSTEM</code> heißt Pseudomodul, weil es dazu weder Definitions- noch Implementierungsteil gibt, sondern alle Kenntnis über dieses Modul direkt in den Compiler eingebaut ist.

== Entwicklung ==

Es gibt zwei Dialekte von Modula-2. Einerseits '''PIM''', die von Niklaus Wirth entwickelten und im Standardwerk
"Programmieren in Modula-2" definierten Varianten. Entsprechend den Auflagen des Buches gibt es die zweite, dritte und vierte Variante von PIM. Mit jeder Auflage wurde die Sprache leicht verändert. Der zweite Dialekt ist '''ISO''', die von einem internationalen Komitee (unter dem Dach der [[International Organization for Standardization]]) erarbeitete Variante.

* '''PIM2''' (1983): Expliziter '''EXPORT''' in Definitionsmodulen.
* '''PIM3''' (1985): Kein expliziter Export in Definitionsmodulen mehr nötig.
* '''PIM4''' (1989): Konkretisierung des Verhaltens des '''MOD'''-Operators, wenn die Operanden negativ sind.
* '''ISO''' (1996): Der Anspruch bei der Entwicklung von ISO Modula-2 war, die Mehrdeutigkeiten von PIM Modula-2 aufzulösen. Außerdem wurden der Sprache die Datentypen '''COMPLEX''' und '''LONGCOMPLEX''', Ausnahmen (Exceptions), die Modultermination ('''FINALLY'''-Klausel) und eine umfangreiche Standardbibliothek für Ein- und Ausgabe hinzugefügt – neben einer Reihe von kleineren Änderungen.<ref>ISO/IEC 10514-1:1996</ref>

== Implementierungen ==

Modula-2 erreichte in den späten [[1980er]] Jahren eine verhältnismäßig große Popularität, insbesondere in der Version von ''Jensen und Partners International'' (JPI), die einen 10-Fenster-Editor in ihrer Entwicklungsumgebung für [[MS-DOS]] und einen sehr schnellen Compiler mit gut optimiertem [[Objektcode]] auf den Markt brachten. Spätere Versionen davon hießen ''TopSpeed Modula-2''.

Entwicklung und Vertrieb der meisten Modula-2-Compiler wurde spätestens in den 2010er Jahren eingestellt. Zum Download verfügbar sind derzeit vor allem der GNU Modula-2-Compiler aus der [[GNU Compiler Collection]] (GCC) und ADW Modula-2 (Stand 2025).

Historische Modula-2-Compiler:
* Aglet Modula-2 – [[AmigaOS]] ([[PowerPC|PPC]])
* Amsterdam Compiler Kit (ACK) Modula-2 – [[MINIX]]
* Gardens Point Modula-2 – BSD, Linux, OS/2, Solaris
* Hänisch Modula-2 – ATARI ST/TT (M68K)
* MOCKA Modula-2 Compiler System – BSD und Linux für x86
* M2Amiga - AmigaOS
* Megamax Modula-2 – [[Atari ST|ATARI ST]](e) ([[M68K]])
* Objective Modula-2 – Cocoa und GNUstep support
* Stony Brook Modula-2, Windows
* XDS Modula-2 – Windows und Linux

== Kritik ==
Wirth selbst<ref>''A Brief History of Modula and Lilith''. In: ''Advances in Modular Languages – Proceedings of the Joint Modular Languages Conference'', Ulm 1994</ref> listet im Zusammenhang mit der Entwicklung von Oberon folgende Probleme von Modula-2 auf:

=== Qualifizierende Importe ===
Die empfohlene Methode zur Verwendung von Bestandteilen fremder Module ist
<syntaxhighlight lang="modula2">
IMPORT M;
</syntaxhighlight>
Dadurch werden alle von <code>M</code> exportierten Bezeichner durch sogenannte ''qualifizierte Bezeichner'', etwa <code>M.A</code>, <code>M.B</code> verfügbar. Alternativ dazu kennt Modula-2 den ''qualifizierenden Import''
<syntaxhighlight lang="modula2">
FROM M IMPORT A,B;
</syntaxhighlight>
Bei diesem Import sind die Bezeichner dann einfach in der Form <code>A</code> bzw. <code>B</code> verfügbar; die Herkunft aus dem Modul <code>M</code> ist an der Verwendungsstelle dann nicht mehr direkt sichtbar. Dadurch können Programmierer Irrtümer begehen. In Oberon gibt es den qualifizierenden Import deshalb nicht mehr.

=== Export von Aufzählungstypen ===
Enthält ein Modul den exportierten Typ
<syntaxhighlight lang="modula2">
TYPE Ampel = (rot, gelb, gruen);
</syntaxhighlight>
so bezieht sich nach der Logik der Sprache ein Import dieses Typs nur auf den Typnamen (<code>Ampel</code>), in Wirklichkeit werden aber die Namen <code>rot</code>, <code>gelb</code> und <code>gruen</code> mitimportiert, was im Falle von Bezeichnerkonflikten an der Verwendungsstelle den Programmierer verwirren kann. In Oberon gibt es Aufzählungstypen deshalb gar nicht mehr, weil man sonst auch ihren Export nicht verhindern könnte.

=== Datentyp CARDINAL ===
Vorzeichenlose Arithmetik funktioniert ganz anders als vorzeichenbehaftete Arithmetik; deshalb sind Ausdrücke, in denen vorzeichenlose und vorzeichenbehaftete Werte gleichzeitig vorkommen, problematisch. Modula-2 hat deshalb solche Mischungen grundsätzlich verboten, was bei den Programmierern auf Protest stieß, weil die Programme durch die Verwendung von Typkonversionsfunktionen unnötig verkompliziert wurden. Darüber hinaus entstehen Unsymmetrien in der Behandlung bestimmter Programmstrukturen und bei der mathematischen [[Division mit Rest#Modulo|Modulo-Funktion]] (<code>MOD</code>).

=== Typtransferfunktionen und andere ''low level''-Vorrichtungen ===
Mit den Typtransferfunktionen (''type casts'') wird es möglich, Eigenschaften der zugrundeliegenden Maschine zu entdecken, die dem Programmierer einer höheren Programmiersprache eigentlich verborgen bleiben sollten, wie etwa die [[Bit-Reihenfolge|Endianness]], das heißt die Frage, in welcher Ordnung die einzelnen [[Bit]]s eines Maschinenworts abgespeichert sind. Je nachdem ist nämlich
<syntaxhighlight lang="modula2">
BITSET(65520) = {4 .. 15}
</syntaxhighlight>
oder
<syntaxhighlight lang="modula2">
BITSET(65520) = {0 .. 11}
</syntaxhighlight>
für eine 16-Bit-Architektur.

== Literatur ==
* [[Niklaus Wirth]]: ''Programming in Modula-2.'' 4. Auflage. Springer, Berlin u. a. 1988, ISBN 0-387-50150-9.

== Einzelnachweise ==
<references />

[[Kategorie:Imperative Programmiersprache]]
[[Kategorie:Programmiersprache mit einem ISO-Standard]]
[[Kategorie:Bildungsorientierte Programmiersprache]]

Modula-2 - Versionsgeschichte

imported>Thomas Dresler: Klammern korrigiert