Mit Pascal ist Niklaus Wirth ein großer Wurf gelungen
von Peter Welchering
Gar nicht so selten wird heute übersehen, dass die Programmiersprache Pascal in der Tradition von Algol60 steht. Das hat Pascal übrigens mit Modula-2 gemeinsam, die auch von Niklaus Wirth entwickelt wurde, der von 1968 bis 1999 als Informatik-Professor an der Eidgenössischen Technischen Hochschule Zürich lehrte und forschte.
„Algol war wie Fortran für numerische Berechnungen gedacht“, erläutert Reinhard Wilhelm, emeritierter Informatik-Professor an der Universität des Saarlandes. Der im Jahre 1977 an der technischen Universität München promovierte Informatiker hat die Entstehungsgeschichte von Pascal hautnah miterlebt.
Fortentwicklung von Algol60 war schwierig
Algol60 unterstützte durch einige Sprachkonzepte wie Rekursion oder dynamische Felder den Programmierer schon wesentlich besser als die konkurrierende Sprache Fortran. „Aber es musste immer noch sehr viel vom Programmierer zu Fuß nachgebildet werden, was er für seine Anwendungen brauchte“, erläutert Reinhard Wilhelm.
Er hat da gleich ein Beispiel parat. „Ich möchte eine Adressdatei programmieren.“ Hier haben wir es überwiegend mit nicht-numerischen Daten zu tun. Name, Vorname, Straße und Wohnort sind Strings, für deren Bearbeitung der Programmierer erst ein Sprachkonstrukt nachbilden muss. Hausnummer und Postleitzahl dagegen sind auch für Algol 60 kein Problem.
Aber Algol60 hatte noch mit einem viel schwerwiegenderen Problem zu tun. „Die Autoren von Algol60 hatten einen gravierenden Fehler gemacht, indem sie die Ein- und Ausgabe als maschinenabhängig erklärten und deshalb nicht in der Sprachdefinition regelten“, erklärt Professor Wilhelm.
Der amerikanische Informatiker Donald Knuth, vielen als Entwickler des Textsatzsystems Tex bekannt, wollte diesen Fehler mit einem eigenen Vorschlag beheben. Er konnte sich damit allerdings nicht durchsetzen. Innerhalb der International Federation for Information Processing (IFIP), der internationalen Dachorganisation der nationalen Informatik-Gesellschaften, führte das zu Diskussionen. Uns so wurde innerhalb der Working Group 2.1, in deren Obhut Algol60 auch entstanden war, beschlossen, eine Nachfolgeversion für Algol 60 zu entwickeln.
Komplexe Implementierung
„Dafür wurde ein Unterkomitee der Working Group eingerichtet“, erinnert sich Reinhard Wilhelm. Das bestand aus dem niederländischen Informatiker Adriaan van Wijngaarden, dem britischen Informatiker Tony Hoare, dem deutschen Gerhard Seegmüller und dem Schweizer Niklaus Wirth. „Während Seegmüller, Hoare und Wirth teilweise sehr detaillierte Vorschläge zur Weiterentwicklung von Algol 60 einbrachten, war van Wijngaarden primär an der Anwendung seiner zwei-stufigen Grammatiken für die Sprachdefinition interessiert“, berichtet Wilhelm.
Gerhard Seegmüller kannte sich mit den Schwierigkeiten von Algol 60 bestens aus. Denn er hatte Algol auf der Programmgesteuerten Elektronischen Rechenanlage München (PERM), einem Röhrenrechner an der technische Universität München, implementiert und darüber seine Dissertation geschrieben.
„Seegmüller war eher auf der pragmatischen Seite angesiedelt und wäre bereit gewesen, Wirth und Hoare zu unterstützen, wenn sie Vorschläge von ihm übernommen hätten, die ihm wegen seiner Implementierungserfahrungen sehr wichtig waren“, erläutert Reinhard Wilhelm.
Das klappte aber nicht. Das Unterkomitee konnte keinen gemeinsamen Vorschlag einreichen. Es gab zwar einen Vorschlag von Hoare und Wirth. „Ihr gemeinsamer Vorschlag, Algol W, zu dem Hoare Verbunde, also Records beigetragen hatte, wurde von der WG 2.1 als nicht weit genug über Algol 60 hinaus gehend abgelehnt“, berichtet Wilhelm und fährt fort: „Schließlich setzte sich van Wijngaarden im Komitee mit seinem Vorschlag für eine Sprache, die später Algol 68 wurde, durch.“
Dieser Ansatz galt als extrem puristisch, Wirth dagegen versuchte es mit einem pragmatischen Vorgehen. „Er übernahm von Algol 60 das Block- und das Prozedurkonzept und die lexikalische Sichtbarkeit von Namen“, sagt Reinhard Wilhelm und erläutert: „Allerdings gab es nur Value- und Referenzparameter und nur statische Felder (arrays). An Datenstrukturtypen gab es mehr als in Algol 60, nämlich Aufzählungstypen, Zeichenketten (strings), Verbunde (records) und vor allen Dingen Zeiger (pointer). Zeiger brauchte man unbedingt, um auf dynamisch kreierte, anonyme Objekte zugreifen und damit verzeigerte Datenstrukturen realisieren zu können. Anonyme Objekte wurden durch den new-Operator in einem speziellen Speicherbereich, der Halde (heap) kreiert und konnten mit dispose wieder freigegeben werden. Speicherverwaltung war also explizit vom Programmierer zu machen. Es gab keine automatische Speicherbereinigung.“
Ein Aufsatz bringt den Durchbruch
Ganz wesentlich zur Verbreitung und Akzeptanz von Pascal trug eine Veröffentlichung in der Zeitschrift „Acta Informatica“ bei. „Die wurde gegen den Widerstand der Gutachter wegen Unvollständigkeit und mangelnder Präzision durch F.L. Bauer zur Veröffentlichung angenommen“, weiß Reinhard Wilhelm und ergänzt: „Die Beschwerden des Gutachters waren: unvollständige Beschreibung von Ein-/Ausgabe, unklare Definition des Typs file.“
Das waren aber bei weitem nicht die einzigen Entwurfsfehler, die auch Reinhard Wilhelm moniert. „Ein Record-Typ konnte mehrere durch Diskriminatoren, also Tags, unterschiedene Instanzen haben. Leider verbot er nicht die dynamische Änderung von Diskriminatoren. Der Programmierer konnte also einen Verbund mit einem Diskriminator anlegen, anschließend das Diskriminator-Feld durch eine Zuweisung umsetzen und dann auf den angelegten Verbund über die Selektoren der falschen Instanz zugreifen. Damit unterlief Wirth seine eigene Philosophie der vollständigen statischen Überprüfbarkeit der Typen. Weiterhin waren die automatische Typkonversion von ganzzahligen zu reellwertigen Typen umstritten, die pack-Funktion zur kompakten Ablage von Daten im Speicher nicht präzise definiert, und Ein-/Ausgabe blieb weitgehend maschinenabhängig.“
Und auch mit einigen Problemlösungen von Niklaus Wirth ist Reinhard Wilhelm nicht so ganz einverstanden: „Da Wirth darauf bestand, dass Pascal-Programme mit einem LL(1)-Syntaxanalysator analysiert werden können sollten, musste er den typischen Konflikt zwischen Variablenbezeichnungen auf der linken Seite von Wertzuweisungen und alphanumerischen Programmmarken, also Labels, los werden. Das tat er, indem er nur numerische Marken zuließ. Diese haben aber leider keinerlei dokumentarischen Wert für das Programmverständnis.“
Portierung im besonderen Einsatz
Pascal fand eine sehr breite internationale Anerkennung. Dazu trugen die viel beachteten Vorträge von Niklaus Wirth bei, aber auch die Tatsache, dass er die an der ETH Zürich vorgenommene Pascal-Implementierung sehr großzügig verteilte. So wurde Pascal sehr breit und umfangreich portiert.
An ein Portierungsprojekt erinnert sich Professor Reinhard Wilhelm noch sehr lebhaft: „Als MS-Student in Stanford war ich an der Portierung von Pascal auf eine IBM 360 durch Dave Russel und Jeff Sue beteiligt. Das schwierigste Problem waren die verschiedenen File-Formate und Zeichencodierungen der CDC 6400, auf der Urs Amman Pascal an der ETH implementiert hatte, und der IBM 360. Die ersten Bootstrap-Schritte mussten auf einer CDC 6400 ablaufen, die Codeerzeugung musste aber IBM 360-Code ausspucken. Im Silicon Valley ist bekanntlich nichts unmöglich. Es fanden sich im benachbarten Stanford Research Institute (SRI) tatsächlich eine CDC 6400 und eine IBM 360, allerdings in verschiedenen Flügeln des SRI-Gebäudes. Wir bekamen die Genehmigung, diese beiden Maschinen zur Portierung zu benutzen. Da das SRI sehr viele vom Pentagon finanzierte Projekte laufen hatte, herrschten strikte Sicherheitsvorschriften. So wurde die Nutzung der beiden Maschinen in den verschiedenen Gebäudeteilen zum Alptraum. Jedes Mal, wenn wir einen Fehler auf einer IBM-Lochkarte hatten, brauchten wir militärischen Begleitschutz zum IBM-Lochkartenstanzer im anderen Flügel. Das hielten alle Beteiligten nicht lange durch, und so wurde der Port irgendwie doch im Gebäude des Computer Science Departments durchgezogen.“
Und Professor Reinhard Wilhelm brachte Pascal dann auch ins Saarland, wenngleich das wesentlich schwieriger war als die unter militärischer Eskorte vorgenommene Portierung in Standford. In Saarbrücken sollte Pascal auf die dort installierte TR440 portiert werden. „Ich kontaktierte einen Herren an der ETH, der mir ein CDC 6400-Band mit dem Züricher Pascal-Übersetzer schickte und übergab dieses an das Rechenzentrum zum Einlesen. Die Mitarbeiter dort taten ihr Bestes, scheiterten aber an dem auf der TR440 unlesbaren CDC-Dateiformat. Ich rief den Herren an der ETH an und fragte ihn, wie all die Empfänger von CDC-Bändern mit dem Pascal-Übersetzer, die nicht selbst CDC-Maschinen hatten, mit den exotischen Datei-Formaten klar gekommen seien, und erhielt in schönstem Schweizer Tonfall, die Antwort: Das habe ich mich auch schon immer gefragt.“
Pascal wurde ein enormer Erfolg. Doch für größere Entwicklungsprojekte hielt die Sprache zu viele Hürden bereit. Es fehlte ein Modulkonzept. „Dies war neben der Nebenläufigkeit die zweite große Neuigkeit in Modula 2“, führt Reinhard Wilhelm aus und erläutert: „Moduln in Modula 2 waren auch Einheiten der Übersetzung. Sie mussten vom Programmierer in zwei Teilen angegeben werden, einem Definitionsmodul und einem Implementierungsmodul. Der Definitionsmodul enthielt Definitionen der vom Modul exportierter Konstanten, Variablen, Typen und Prozeduren zum Gebrauch in anderen Moduln. Der Implementierungsmodul enthielt den Code für die Prozeduren. Nebenläufigkeit wurde durch das Koroutinenkonzept unterstützt.“