Die Geschichte der Programmiersprache LISP

 

Einleitung

LISP ist als Programmiersprache für die Kommunikation zwischen Mensch und Rechenanlage gedacht, Programme müssen jedoch erdacht und entwickelt werden, Programmierer unterhalten sich über sie und benutzen sie, um bestimmte Ideen deutlich zu machen. In vielen Fällen werden Programme nie in maschinenlesbare Form gebracht, sie sind wichtig als Programmierversuche, als Ansätze, ein neues Problem verstehen zu lernen.

Aus diesen Gründen ist abzuleiten, da\ssjede Programmiersprache eine soziele Erscheinung ist. Es genügt zu ihrer Charakterisierung keinesfalls, sie als Menge zugelassener Zeichenfolgen zu sehen und lediglich Fragen ihrer Erkennung, Verarbeitung und Beschreibung anzugehen. Die Pragmatik hat Vorrang gegenüber Syntax und Semantik.

Es ist stets eine gute Verfahrenweise, zum Studium einer sozialen Erscheinung ihre Geschichte zu analysieren. So werden die notwendigen und zufälligen Gründe ihres So-seins deutlich, kann die Wirkung auf die menschliche Gesellschaft betrachtet werden. Bei einem Objekt wie bei einer Programmiersprache, das zum Gebrauch von Menschen gemacht wurde, kann man überdies versuchen, festzustellen, inwieweit das fertige Produkt sich bewährt hat und wie im Verlaufe der Zeit durch neue Ansprüche und akkumuliertes Wissen über die Eigenschaften dieses Objekts zu Veränderungen oder Neuentwürfen geschritten wird.

Sicher wird man die pragmatische und weiter ausgreifend die soziale Komponente bei vielen wichtigen und durchaus berechtigten wissenschaftlichen Arbeiten über Programmiersprachen vernachlässigen dürfen. Wer aber meint, eine Programmiersprache ohne diese Überlegung entwickeln zu können, braucht sich nicht zu wundern, wenn seine Sprache kaum benutzt wird.

Die Geschichte einer Programmiersprache, die nicht nur deren ursprüngliche Entwicklung, sondern auch die Verbreitung, Benutzung und Weiterentwicklung zum Gegenstand haben muß, ist natürlich wesentlicher Bestandteil der Geschichte der Informatik. Der hiermit unternommene Versuch, für die Sprache LISP ihre Historie zu schreiben, ist damit ein Beitrag zur jüngeren Wissenschaftsgeschichte.

 

Die Entstehung von LISP

Die Programmiersprache LISP ist die Antwort eines Mannes, John McCarthy, auf die Formulierungs- und Notationsprobleme für Programme am Ende der fünfziger Jahre. Sicher hat McCarthy in enger Diskussion mit einem Kreis von Freunden und Bekannten (unter ihnen ist schon jetzt Marvin Minsky hervorzuheben) gestanden, und so mag manche Detaillösung von anderen stammen -- in einigen Fällen ist dies explizit bekannt. Um jedoch die Vorgeschichte von LISP ins Auge fassen zu können, mu\ssman McCarthys Aktivitäten jener Zeit betrachten.

McCarthy, geboren im Jahr 1927, studierte Mathematik und erreichte 1948 den akademischen Grad eines Bachelor of Science am California Institute of Technology (Caltech). 1951 promovierte er mit einer Arbeit über Differentialgleichungen an der Princeton University.

Das Interesse an Fragen, wie intelligente kybernetische Systeme zu schaffen seien, war ihm gekommen, als er 1949 ein Symposium über Fragen der Kybernetik am Caltech erlebte und dort unter anderen Johann von Neumann hörte. So beschäftigte er sich nebenbei mit ähnlichen Problemen und schrieb eine Arbeit über die Invertierung von Turing-Maschinen, in der er einige seiner Ansichtendarstellte [MCC56a]. Dieser Artikel, nach Minskys Ansicht in seiner Bedeutung völlig unbemerkt, erschien 1956 in der Automata Studies, einem Sammelband, den McCarthy zusammen mit C.E.Shannon über die Princeton University herausgab.

Eine intensivere Beschäftigung begann, als Shannon McCarthy in die Bell Telephone Laboratorien im Sommer 1952 einlud. Dort hielt sich zu dieser Zeit ebenfalls Minsky, der noch in Princeton studierte, auf. Gemeinsam arbeitete man über Fragen der Beziehung von Kybernetik und Algorithmentheorie.

Als McCarthy 1956 Assistant Professor für Mathematik am Dartmouth College in Hannover, New Hampschire, wurde, war er mit beiden immer noch freundschaftlich verbunden. Inzwischen war ihnen die Erkenntnis gekommen, da\ssstatt kybernetischer Modelle und Maschinen die elektronischen Rechner zur Erreichung maschineller Intelligenz besser geeignet seien. Sie hatten auch von anderen Forschen auf diesem Gebiet gehört, die in anderen Städten der USA zu ähnlichen Resultaten gekommen waren. So hatte man die Idee, alle zu einem Arbeitssommer ins Dartmouth Collge einzuladen, zur Dartmouth Summer School on Artificial Intelligence. In einer Bitte an dieRockefellerstiftung um Unterstützung schrieb McCarthy von ``einem zweimonatigen Studium von 10 Mann... Das Studium soll auf der Basis der Vermutung aufbauen, da\ssjeder Aspekt des Lernens oder einer beliebigen anderen Eigenschaft von Inteligenz so präzise beschrieben werden kann, da\sseine Maschine zu ihrer Simulation verwendbar ist''[MCCO77].

Obwohl niemand erwartete, da\ssdie Gruppe ihre hochgesteckten Ziele erfüllen würde (nach McCarthys Worten würde das Unterstützungsgesuch noch heute, nach Auswechslung einiger Namen, Daten und Geldbeträge, durchaus sinnvoll sein), bekam man das Geld, und der Sommer konnte beginnen.

Unter der Teilnehmern -- außer den erwähnten drei Einladern kamen N.Rochester von IBM, O.Selfridge und R.Solomonoff vom MIT Cambridge und T. Moore und A.Samuel wiederum von IBM -- waren auch zwei, die bereits Erfahrung bei der Verwendung elektronischer Rechner hatten: A.Newell und H.Simon. Andere Interessenten kamen für kurze Zeit, und es ist kurios zu hören, da\sseiner von diesen A.Bernstein war, der an einem Schachprogramm arbeitete, das bald darauf zum Leidwesen seiner Firma, IBM, öffentlich bekannt wurde: IBM fürchtete, da\ssdie erwarteten Käufer vor dem Erwerb allzu kluger Rechner zurückschrecken würden [MCCO77].

Newell und Simon hatten für den damals bei der RAND-Corporation aufgestellten Rechner JOHNNIAC Programme zum Beweisen und Manipulieren logischer Theoreme aufgestellt. Da man zu jeder Zeit die Bedeutung der Hardware überschätzte, nannten sie ihr System ``logic theory machine'' -- heute hätten sie schon am Anfang von einer neuen Programmiersprache gesprochen. Sie hatten aber schon erkannt, da\ssein Formulierungsmittel in einem solchen System nötig war. Die logische Sprache LL in ihrem informationsverarbeitenden System sollte aber mit Fähigkeiten zur Listenverarbeitung ausgerüstet sein -- ``eine der wichtigsten Ideen, die jemals in der Programmierung aufkam''(J.Sammet [SAM69]).

IPL (Information Processing Language), wie diese dann genannt wurde, war schon im Sommer 1956 soweit entwickelt -- man arbeitete vermutlich schon an der Implementierung von IPL II --, da\sssie von den Autoren auf Konferenzen und Tagungen präsentiert und zur Diskussion gestellt werden konnte [NEW56].

Auf Grund ihres niedrigen (d.h. maschinennahen) Niveaus (``...abgeleitet vom Format eines Laders für die JOHNNIAC, der ihnen verfügbar war...'' [MCC78a]) löste IPL keine ungeteilte Begeisterung bei den Anwesenden aus. Man hatte nämlich im Frühjahr 1956 erste Berichte über den Formelübersetzer von IBM gehört -- die Sprache FORTRAN war über ihr Entwicklungsstadium hinaus [FOR54] und konnte angewandt werden [FOR56]. McCarthy, der Visitor bei IBM war, hattezwar nur ganz lockeren Kontakt zu dieser Entwicklung, doch beeindruckte ihn die Grundidee, Programme mit algebraischen Mitteln, d.h. mathematischen Ausdrücken, zu schreiben. Alles, was man wußte, war, da\ssman bei der Erreichung künstlicher Intelligenz mit symbolischen Ausdrücken würde arbeiten müssen -- numerische Berechnungen sollten wenig Bedeutung haben. Und man konnte sich leicht vorstellen, da\ssbeliebige Teilausdrücke äußerst günstig durch Komposition derFunktionen erhalten werden könnten, die die direkten Teile liefern.

Dennoch hatte IPL großen Einfluß. Neben den Listenstrukturen darf die Programmierbarkeit rekursiver Programme genannt werden, obwohl die Implementationstechnik zur dieser Zeit noch nicht weit entwickelt war. So wurden Kellerspeicher durch Listen repräsentiert, was zu sehr langsamen Aufrufmechanismen führte. Sie sind hier aber zum ersten Male verwendet worden.

Weitere Beiträge von IPL zur Programmiertechnologie werden von Sammet [SAM69][S.400] zusammengefaßt: ``Die hierarchische Unterprogramm-Implementation ist einfacher als in FORTRAN oder ALGOL... Attributwertlisten zeigten sich als wichtige Datenstruktur... IPL führte ein Konzept und sichere Mittel für die dynamische Erweiterung der Datenbereiche ein, soweit das während des Programmlaufs nötig ist...''. Für das spätere LISP dürften auch die Protokollierungsmittel (tracing facilities) von Bedeutung gewesen sein, die IPL anbot.

1956 war IPL allerdings wenig mehr als eine lose Menge ``von Kommandos auf dem Assemblersprachenniveau für die Listenverarbeitung'' ([SAM69], S.383). Implementiert wurde IPL II [NEW57a, b] auf einer JOHNNIAC der RAND-Corporation. IPL III und IPL IV stellten Zwischenstufen zu IPL V dar, das Ende 1957 vorlag. Eine Implementation auf einer IBM 650 am Carnegie Institute of Technology lief Anfang 1958, die Endversion im Sommer 1959 auf der IBM704 [NEW60]. IPL V war seinerzeit eine der meistimplementierten Sprachen ([SAM69], S.389).

Obwohl McCarthy die äußere Form der Sprache nicht anzog, beeindruckte ihn die Realisierung sehr. Die Listenstrukturen -- seinerzeit oft NSS-memory\footnote{von Newell, Shaw} und Simon als Autoren von IPL, vgl. z.B. [GE60a.] genannt -- schienen sehr flexibel und für die Aufnahme komplexer logisch-symbolischer Informationen höchst geeignet. Angesichts dieser Bewertung seiner damaligen Wertung von IPL ist allerdings P.W.Abrahams' Erinnerung ``Der ursprüngliche Entwurf von LISP kommt in Wirklichkeit von Newells und Simons IPL. In den ersten paar Memos, die McCarthy über diesen Gegenstand schrieb, war es IPL sehr ähnlich, aber mit einigen neuen Ideen'' nicht korrekt oder mindestens außerorderlich in die Irre führend.

Sicher ist jedenfalls, da\ssMcCarthy seit Mitte 1956 über ein Formulierungsmittel nachdachte, und da\ssFORTRAN für ihn sehr attraktive Eigenschaften hatte. Unter diesen erschien es ihm besonders wichtig, da\ssman in FORTRAN [FOR56] Funktionsausdrückeverschachteln und so in einer Zeile einen recht komplizierten Umformungsschritt ausdrücken konnte. Dabei ist es durchaus möglich, da\sser schon 1956 daran dachte, auf diese Weise neue Funktionen einzuführen. Hier ging McCarthy, möglicherweise mit Informationen von IBM, der Zeit voraus, denn erst FORTRAN II [FOR58] verfügte über das Function Statement, das vor dem eigentlichen Programm zu notieren war und mit dem solche Funktionsdefinitionen vollzogen werden konnten. Dies wurde Anfang 1957 bekannt gemacht [B57].

Die Überlegungen von McCarthy waren bezüglich einer etwaigen Realisierung ziemlich früh an die IBM704 gekoppelt. Dazu gab es zwei Gründe: IBM wollte am MIT Cambridge ein Rechenzentrum für Neuengland etablieren, und außerdem schien es, als wollte IBM Forschungen auf dem Gebiet der Künstlichen Intelligenz großzügig fördern. So wurde, wahrscheinlich Anfang 1957, auf Initiative Rochesters, der damals Leiter des Information Research Department amForschungszentrum in Poughkeepsie war, an die Realisation einer von Minsky auf der Sommerkonferenz geäußerten Idee gegangen: ein Programm zum Beweis geometrischer Aussagen aufzustellen.

H.Gelernter, der gerade promoviert hatte und seit dem Herbst 1956 bei IBM arbeitete, wurde für dieses Projekt interessiert, und McCarthy sollte als Berater fungieren. Die Verbindung scheint zunächst recht eng gewesen zu sein, solange die grundsätzlichen Entscheidungen über Sprache und Implementation zur Debatte standen. Später, als das eigentliche Programm zum Beweis geometrischer Sätze angegangen wurde, ist der Kontakt äußerst lose gewesen.

Um die symbolischen Informationen in der Maschine darzustellen, wie z.B. die geometrische Aussage, da\sszwei Dreiecke kongruent sind, wollte man Listenstrukturen verwenden. So konnte McCarthy seine Ideen einbringen, die er in Dartmouth entwickelt hatte: Er schlug die Verwendung von FORTRAN für die Programmierungsarbeit vor. ``... es gab gewisse Überlegungen bezüglich der Überführung des JOHNNIAC IPL auf den IBM704-Rechner. Jedoch empfahl McCarthy, der das Projekt beriet, da\ssFORTRAN so angepaßt werden könnte, da\sses denselben Zweck erfülle. Er führte aus, da\ssdie Verschachtelung von Funktionen, die in FORTRAN erlaubt ist, die Konstruktion komplizierter informationsverarbeitender Unterprogramme mit einzigen Statement möglich mache. Die Autoren haben seither einen weiteren wesentlichen Vorteil einer algebraischen Listenverarbeitungssprache wie der, die innerhalb des Gerüsts von FORTRAN errichtet wurde, entdeckt. Es ist die enge Analogie, die zwischen der Struktur einer NSS-Liste\footnote{vgl. Fußnote auf S.136} und einer gewissen Klasse von algebraischen Ausdrücken existiert, die in der Sprache geschrieben werden können...''[GE60aq][S.88].

Von McCarthy kamen die meisten Vorschläge, wie die Listenstrukturen im Speicher der IBM704 darzustellen wären und welche Grundfunktionen geeignet seien. Ein Wort (register) der IBM704 bestand aus fünf Teilen: Vorzeichen, Präfix, Dekrement, Kennzeichen (Tag) und Adreßteil.

\begin{picture}(400,130)


0 1 2 3   17 18 20 21   35
        Dekrement-Teil         Adress-Teil  
        (Zeiger aufs         (Daten oder  
        Nächste Element)         Zeiger auf Liste)  

\put(11,15){Präfix (Typinformation)}\put(10,20){\line(0,1){30}} \put(211,15){Tag (Daten)}\put(210,20){\line(0,1){30}} \put(0,0){Vorzeichen (sign)}\put(5,3){\line(0,1){60}} \end{picture}

\begin{center}Abb. 4.1. Wortstruktur der IBM/704 und die FLPL-Interpretation [GE60a]\end{center}

In den Dekrementteil paßte genau eine 15-Bit-Adresse. Damit sollte auf das nächste Listenelement gezeigt werden. Auch der Adreßteil hatte diese Größe: Man wollte ihn zur Aufnahme von Daten oder von Zeigern auf solche Listen benutzen, die Elemente der umfassenden Liste sind. Im Tag hoffte man Informationsbits unterzubringen und im Präfix einen Typcode, der für die Speicherverwaltung erforderlich war.

Neben diesen Listenworten sollte es auch solche geben (Koordinatenwerte usw.), die ganz mit einer Zahl, d.h. einem Datum, ausgefüllt waren.

Die Speicherverwaltung verlief weitgehend nach IPL-Vorbild: Der Begriff des Ausborgens von Elementen wurde gebraucht, und explizite Löschungsaktionen mußten veranlaßt werden.

Die Grundfunktionen für die Listenverarbeitung wurden so in das verfügbare FORTRAN-System eingebettet, da\sssie das Grundvokabular erweiterten. Damals war es anscheinend noch nicht möglich, Unterprogramme in Assemblersprache zu FORTRAN-Programmen hinzuzufügen. Entsprechend den erwarteten Notwendigkeit wurden Funktionen für

 

``(a) information retrieval, (e) list generation,
(b) information storage, (f) service routines,
(c) information processimg (g) special purpose functions''
(d) information search,   ([Ge60a], S.94)

implementiert.

Ausgehend von der Adresse eines Wortes (d.h. Anfang einer Liste) ermöglichten die Funktionen für den Information-Retrieval die Herauslösung des Inhalts jedes beliebigen Teilfeldes. In Anlehnung auf die Namen der Teile wurden die Funktionen XCSRF (contents of sign part of register), XCPRF (contents of prefix part of register), XCTRF ({\em contents of tag part or register}) und XCARF (contents of adress part of register) eingeführt.

Eine Funktion hatte also eine Quantität von einem Bit zum Wert, eine andere eine von zwei Bits, weitere solche von drei Bits und schließlich zwei solche von 15 Bits. Sie wurden ergänzt durch eine Funktion XCWWF, die einen ganzen Wortinhalt lieferte und durch XTRACTF, die einen beliebigen Bitteil abspaltete.

Entsprechend den Retrieval-Funktionen konnten auch die Speicherfunktionen einzelne Teile eines Wortes ändern. Unter den Funktionen zur Listenerzeugung sind die beiden Funktionen XDWORDF und XLWORDF interessant, die ein bzw. vier Argumente hatten und mit diesen Argumenten das nächstverfügbare Wort in der Freispeicherliste belegten und diese Liste um dieses Wort verkürzten.

McCarthy war sich, wie er berichtet, über den Wert der Listenerzeugungsfunktionen nicht klar, ja er erkannte sie überhaupt nicht als Funktionen.

Eine wesentliche Schwierigkeit im Erfassen und Beurteilen der geschaffenen ``Funktionen'' war die Tatsache, da\ssman sich im Begriffsysstem von FORTRAN bewegte, wo es praktisch als Datenstrukturen nur Zahlen gab. Wie sollte man eine der Selektorfunktionen als echte Funktion verstehen, die Zahlen auf Zahlen abbildet? ``Die vorherrschende Charakteristik der meisten unserer Listenverarbeitungsfunktionen ist, da\sssie überhaupt keine Funktionen im gewöhnlichen Sinne des Wortes sind. Für viele von ihnen hängt der Wert der Funktion nicht nur von ihren Argumenten ab, sondern auch von dem speziellen internen Zustand des Rechners zu der Zeit, wenn sie ausgewertet wird. Außerdem haben einige der Funktionen nicht nur numerische Werte, sondern produzieren auch Änderungen im internen Rechnerzustand, wenn sie ausgewertet werden...'' [GE60a][S.93].

Offenbar hat diese Unsicherheit dazu geführt, da\ssman den Listenverarbeitungsfunktionen als ersten Buchstaben ein X voranstellte. McCarthy erfaßte die Besonderheit der Listenverarbeitungsfunktionen erst dann, als er sie als Funktionen über der Datenstruktur der S-Ausdrücke verstand.

Im Gegensatz zu dieser theoretischen Unsicherheit zeigte sich nach und nach, da\ssdie Funktion fehlerlos wie richtige Funktionen über Zahlen verschachtelt und einzeln benutzt werden konnte. Gelernter und C.L.Gerberich, einer der Programmierer, fanden weiterhin heraus, da\ssdie Funktionen XDWORDF und XWORDF zum Wert eine 15-Bit-Quantität in Form der Adresse des neu konstruierten Listenelements haben müßten, damit sie für Verschachtelungen gut geeignet wären.

Die IBM-Gruppe wurde nach und nach selbstständig und bestimmte schließlich unabhängig von McCarthy ihre weitere Arbeitsrichtung. Aus den einzelnen zu FORTRAN hinzugefügten Funktionen wurde schließlich ein regelrechtes System, das sie FLPL (Fortran List Processing Language) nannten [HAN60]. Dieseswurde später unabhängig vom Geometrietheorembeweiser benutzt und auch vertrieben.

Die Arbeit an FLPL ist von Gelernter, Gerberich und später auch von J.R.Hansen fortgesetzt worden. Der erste erfolgreiche Beweis eines geometrischen Theorems wurde im Frühjahr 1959 durchgeführt; erste Resultate bei der Verwirklichung der Idee von Minsky wurden auf der ersten IFIP-Konferenz 1959 in Parisveröffentlicht [GE59]. Weitere Ergebnisse können in [GE60a,GE60b,HAN60] studiert werden.

Brief an Morse vom Dezember 1957...

Aufnahme in ACM-Ad-Hoc-Gruppe im Januar 1958...

Vorschlag dieser Gruppe vom Mai 1958...

Brief an Perlis und Turanski vom Juni 1958...

Im Sommer 1958 wurde McCarthy zu einem Arbeitsaufenthalt bei IBM eingeladen. Inzwischen hatte er sich mit einem Schachprogramm beschäftigt, das sich ganz auf die Mittel des normalen FORTRAN beschränkte. Da die bedingte Anweisung, die FORTRAN enthielt, das sogenannte arithmetische IF, mit seiner Einengung auf Vergleiche mit 0 und die an das Maschinenniveau erinnernde Dreiteilung des Steuerflusses ihm nicht gefiel, benutzte er eine eigens erfundene Funktion für Bedingungen. Diese hatte drei Argumente und lieferte den Wert des zweiten bzw. des dritten, wenn das erste Argument 0 bzw. 1 war. Natürlich ermöglichte diese Funktion manche programmtechnische Verbesserung, allerdings war sie in ihrer Bedingung an den FORTRAN-Mechanismus immer noch unschön. Es wurden nämlich alle drei Argumente berechnet, bevor die Funktion arbeitete, während tatsächlich immer nur zwei benötigt würden -- die Bedingung und die ausgewählte Folge.

Da McCarthy in diesem Jahr einige Zeit hatte -- er hatte ein Forschungsstipendium der Sloan-Stiftung -- dachte er intensiv über das Problem nach und entwickelte die Idee der bedingten Ausdrücke. Ein Artikel zu diesem Thema sandte er an die Communications ACM ein, der dort allerdings zu einem ``Brief an den Herausgeber'' umfunktioniert wurde [MCC59a].

Die Besonderheit an dieser Erfindung ist die Verschachtelbarkeit der bedingten Ausdrücke und die Beschränkung der Rechnung auf die Teile, die zu den Bedingungen bzw. ausgewählten Folgen gehören. Gegenüber dem IF-Statement als auch einer IF-Funktion ergibt sich damit sowohl eine Steigerung der Effizienz als auch der Ausdruckskraft, was zu völlig neuartigen Anwendungsmöglichkeiten führt.

McCarthy spürte die Bedeutung seiner Idee und versuchte, sie dem ALGOL-Komitee als nützlich nachzuweisen, hatte aber damit keinen Erfolg [MCC74]. ``Ich machte eine Menge Propaganda für die Aufnahme bedingter Ausdrücke in ALGOL ... und 1958 verlor ich, denn die Idee war zu ungewöhnlich, und ich erklärte sie nicht gut genug; so hatte ich kein Erfolg, diese Sache in ALGOL 1958 hineinzubekommen.'' Erst 1960 konnte McCarthy das ALGOL-Komitee, dessen Mitglied er nun war, umstimmen. Allerdings wurde eine andere Syntax bevorzugt, die J.Backus vorschlug, denn man wollte erreichen, da\ssalles, was nicht durch englische Schlüsselwörter ausgedrückt wurde, der mathematischen Notation entspräche.

In diese Zeit fällt auch die Verknüpfung der bedingten Ausdrücke mit den rekursiven Funktionen, denn ``die Idee der Differentiation ist offensichtlich rekursiv'' [MCC78a]. Eine weitere wesentliche Entdeckung betraf die Brauchbarkeit funktionaler Argumente. Will man Summen mit vielen Summanden differenzieren, so mu\ssauf jeden von ihnen der Differentialoperator angewandt werden. McCarthyfand es höchst einfach und übersichtlich, eine Funktion maplist einzuführen, die ein gegebenes funktionales Argument auf alle Elemente einer Liste anwendet und alle Ergebnisse zu einer neuen Liste zusammenfaßt.

Damit war jedoch die Frage gestellt, die funktionale Argumente zu notieren seien.

Mit diesen neuen Formulierungsmitteln war das Differentiationsprogramm in FLPL nicht implementierbar. Überhaupt genügte FORTRAN als Sprachbasis nicht mehr, aber das IBM-Team wollte sich auf eine solch drastische Änderung nicht einlassen. Außer dem schien ihnen die Brauchbarkeit der Neuheiten höchst fragwürdig [MCC78a].

Eine neue Sprache schien notwendig zu sein, und es war ein Glück für McCarthy, da\sser eine materielle Basis bekam, auf der er aufbauen konnte: Im Herbst 1958 wurde das MIT Artifical Intelligence Project ins Leben gerufen. McCarthy wurde Assistant Professor im Department for Electric Ingineering (sein Fach war Kommunikationswissenschaft), Minsky Assistant Professor imDepartment für Mathematik. Vom Forschungslabor für Elektronik (R.L.E.) bekamen sie Unterstützung in Form zweier Programmierer, einer Sekretärin und einer Schreibmaschine sowie sechs anzuleitende Studenten.

Den Stand von McCarthys Vorstellungen über seine neue Sprache gibt das 1. Memo wieder, das er vermutlich Anfang September 1958 am MIT verfaßte. Es zeigt weiterhin Unsicherheit bei den Listenverarbeitungsfunktionen, Verwendung der 3-Bit-Quantitäten, IPL-ähnliche Speicherverwaltung, bedingte Ausdrücke, deklarative Teile (Vereinbarungen von P-Listen) sowie funktionale Argumente ohne Verwendung von $\lambda$ [MCC58a].

Die Arbeit ist das wichtigste Dokument vor dem ersten Entwurf für die ``Recursive functions ...''. McCarthy beschäftigte sich in ihr mit den Anwendungsbereichen der Sprache, den wichtigsten Sprachelementen und einigen Implementationsdetails. Daneben behandelte er die Besonderheiten der neuen ``algebraischen Sprache für die Manipulation symbolischer Ausdrücke'' wie der Titel des Memos lautet.

Die von McCarthy anvisierten Anwendungsgebiete sind Teilgebiete der Symbolmanipulation: Manipulation von Sätzen in formalen Sprachen -- wichtig für das {\em Advice Taker Project} --, Vereinfachung und Differentiation algebraischer Ausdrücke und Compilerprogrammierung für die Sprache selbst. Er betonte die Eignung der Sprache für die Formulierung heuristischer Programme, weil sie sehr geeignet sei, ``Bäume alternativer Aktionen'' darzustellen.

Die Sprache stellte McCarthy vor, indem er die Basisdatenstrukturen, die Anweisungsarten und einige Beispielprogramme durchsprach bzw. angab.

Als Datenstrukturen waren vorgesehen: ganze Zahlen (als Indizes oder Adressen), ganze Worte, die vielleicht als Gleitkommazahlen interpretiert werden können, Wahrheitswerte, sogenannte ``Locational Quantities'', d.h. Adressen im Programm selbst, wie Sprungmarken u.dgl. und schließlich ``Functional Quantities'', um funktionale Argumente als Daten verstehen zu können.

Der Verzicht auf die Datenstruktur ``Liste'' und statt dessen die alleinige Benutzung der Adreßzahlen weist wiederum auf die theoretischen Probleme hin, in FORTRAN über Funktionen von Listen zu sprechen. Übrigens hatte noch LISP1 [MCC60b] zwar eine Gleitkommaarithmetik, aber keine solche für ganze Zahlen! Im Zusammenhang mit den Grundfunktionen kommen wir noch ein weiteres Mal auf dieses Problem zu sprechen. An dieser Stelle begründete McCarthy zunächst das Auslassen der Listen: ``Dies (die Auslassung, d. Verf.) ist, obwohl eine Zahl interessanter und nützlicher Operationen an ganzen Listen definiert worden sind, weil die meisten der Rechnungen, die wir in Wirklichkeit ausführen, bis jetzt nicht mittels dieser Operationen beschrieben werden konten...'' ([MCC58a], S.5). Das bedeutetalso, da\ssman Prozeduren, die aus einer Liste ein Element abspalteten, oder eine zugeordnete Zahl (etwa die Länge) ermittelten, nicht als Verwirklichungen von echten Funktionen ansah. Es darf angenommen werden, da\ssdafür nicht allein die FORTRAN-Begriffsweltverantwortlich war, sondern auch der zeitgenössische Stand der Implementation von Listenstrukturen die Sicht verstellte. Nicht umsonst wurde diesem Punkt immer wieder soviel Platz eingeräumt.

Obwohl Listen also nicht als Datenstrukturen der Sprache galten, konnte man sie doch einlesen. Die externe Notation war

\begin{center}{\tt ($e_{1}$, $e_{2}$, $e_{3}$, $...$ , $e_{n}$)},\end{center}

wobei die $e_{i}$ Unterlisten oder Symbole sind. Neben den Listen sollten Zahlen, Symbole, Gleitkommazahlen und Text eingelesen werden können. Über die Art, wie der Text für eine solche Eingabe zu präparieren sein sollte, sind keine Angaben enthalten.

Die algebraische Sprache sollte wie FORTRAN eine Reihe von Anweisungen erlauben. Neben dem arithmetischen (FORTRAN-Terminologie) oder Ersetzungsstatement sollten verfügbar sein: Ein go-Statement, ein set-Statement,Unterprogrammaufrufe, deklarative Sätze, ein compound-Statement, passende Anweisungen zur Iteration und schließlich Elemente zur Definition von Unterprogrammen.

Die Zuweisung (arithmetisches Statement) sollte vermutlich wie in FORTRAN die wichtigste Anweisung sein. Auf der rechten Seite durften beliebige Ausdrücke, zusammengesetzt aus einfachen Funktionsausdrücken durch Verschachtelungen, logische Verknüpfungen und bedingte Ausdrücke stehen, während auf der linken Seite Variablen, indizierte Variablen (deren Verwendung noch etwas ungewi\sswar) und Ausdrücke stehen, durch die ein gewisser Teil eines Wortes ausgewählt wurde. So sollte z.B. eine Zuweisung

\begin{center}car(i) = cdr(j)\end{center}

möglich sein.

In der Sprunganweisung

\begin{center}\tt go(e)\end{center}

sollte der Argumentausdruck berechenbar sein (vom Typ Locational Quantity).

Durch die Zuweisungsmenge

\begin{center}\tt(A; $q_{1}$, $...$, $q_{m}$)\end{center}

sollte eine Menge von Zuweisungen gleichzeitig ausgeführt werden. Durch die Anweisung wird ein Feld A mit den Dimensionen 1, ... , $m$ aufgebaut, der die Werte der $q_{i}$ in naheliegender Weise zugewiesen bekommt. Diese können dann später als dann später als A(i) weiterverwendet werden.

Der Unterprogrammaufruf sollte ohne das in FORTRAN erforderliche Schlüsselwort CALL notiert werden.

Durch die deklarativen Sätze (sentences) sollten P-Listenstrukturen vereinbart werden. Ihre allgemeine Form sollte

\begin{center}{\tt I declare ($dcl_{1}$, $dcl_{2}$, ..., $dcl_{n}$)}\end{center}

sein, wobei die einzelnen Deklarationen zwei verschiedenen Mustern entsprechen sollten: Durch

\begin{center}{\tt ($a$: $p_{1}$, $p_{2}$, $...$, $p_{n}$)}\end{center}

sollte dem a entsprechenden Symbol die Werte der Ausdrücke $p_{1}$ bis $p_{n}$ nacheinander in die P-liste gestellt werden. (``Jedes Symbol im Programm hat solch eine Eigenschaftsliste, die benutzt und erweitert wird durch den Compiler, aber auch dem Objektprogramm verfügbar gemacht wird''.) Durch

\begin{center}\tt($a_{1}$, $a_{2}$, ..., $a_{n}$, $p$)\end{center}

wird erreicht, da\ssder Ausdruck p den Symbolen, die den $a_{i}$ entsprechen, in die P-Liste gestellt wird. Vermutlich sollte das letzte Komma ein Semikolon sein.

Von Indikatoren oder P-Listenzugriffsfunktionen ist allerdings noch nirgendwo die Rede.

Die Verbundanweisungen sollten aus einer Folge von geklammerten einfachen Anweisungen bestehen. ``Die Symbole, die für diese `vertikalen Klammern' benutzt werden sollen, sind noch nicht bestimmt.'' In den Beispielprogrammen verwendet McCarthy die Klammern / und $\backslash$. Wenn eine ganze Funktion aus einem Ausdruckbesteht, werden die Anweisungsklammern nicht benötigt.

Die Form der Iterationsanweisungen war noch nicht festgelegt. ``...sie sollte die FORTRAN-Art umfassen, sowie ein DO über eine explizit gegebene Liste...''[MCC58a][S.9].

Auch die Unterprogrammdefinition sollte der entsprechenden FORTRAN-Sprachform weitgehend ähneln. Zusätzlich sollten aber Funktionen und Locational Quantities (und Ausdrücke aus denselben) als Parameter vorkommen, sie sollten separat compilierbar sein, und symbolische Referenzen zu anderen Variablen zu Subroutinen sollten garantiert werden.

Die für die Listenmanipulation vorgesehenen Funktionen waren aufgeteilt in die für Basisoperationen bezüglich ganzer Listenstrukturen und in die Basisfunktionen für einzelne Worte (basic single word functions). {\tt

 /copy = (J=0 $\rightarrow$ 0, 1 $\rightarrow$ consw (comb 4(cpr(J), copy
(cdr(J)), ctr (J), (cir (J) = 0 $\rightarrow$ car (J), cir(J) = 1
$\rightarrow$ consw (cwr (car (J))), cir (j) = 2 $\rightarrow$ copy (car (J))))))
  $\backslash$return 

}\begin{center}a) die Funktion copy(J)\end{center}{\tt

  equal (L1,L2) = (L1 = L2 $\rightarrow$ 1, cir (L1) $\neq$ cir (L2)
$\rightarrow$ 0, cir (L1) = 0 $\wedge$ car (L1) $\neq$ car (L2) $\rightarrow$ 0, cir (L1)
= 1 $\wedge$ cwr (car(L1)) $\neq$ cwr (car(L2)) $\rightarrow$ 0, car(L1) = 2 $\wedge$ $\sim$
equal (car(L1), car (L2)) $\rightarrow$ 0, 1 $\rightarrow$ equal (cdr(L1), cdr(L2))

}\begin{center} b) die Funktion equal(L1, L2)\end{center}\begin{center} Abb. 4.2. Notation in Lisp, September 1958 [MCC58a]\end{center}

Die ersteren wurden durch die Funktionen eralis(j),copy(j), {\tt search({\em l, j, $p_{1}$, $p_{2}$, $p_{3}$, m})},maplist(l, j, f(j)) und {\tt list($j_{1}$, ..., $j_{n}$)} exemplifiziert. Dabei löschte eralis eine gesamte Listenstruktur und führte sie der Freispeicherliste zu, copy kopierte eine Listenstruktur, search suchte in l nach dem ersten Element, das der Bedingung $p_{1}$ genügte, {\ttmaplist} bildete eine neue Liste, deren Elemente von der Ausgangsliste l durch Anwendung der Funktion f(j) auf jedes Element j gebildet wurde list bildete eine Liste von n Elementen. Zusätzlich wurde an die Funktion equal gedacht.

Die Basisfunktionen für einzelne Worte betrachtete McCarthy nicht als Realisierungen echter mathematischer Funktionen. Zur Begründung gibt er ziemlich genau dieselben Eigenschaften der Selektorfunktionen an, die schon von Gelernter im Zusammenhang mit FLPL betont worden sind: Speicherabhängigkeit und Seiteneffekte.

Im Unterschied zu FLPL hatte McCarthy sich zwei Mengen von Zugriffsfunktionen ausgedacht: Solche, deren Argument ein wirkliches Rechnerwort sein sollte, und solche, deren Argument die Adresse eines solchen Wortes zu sein hätte. Grundlage für die Bezeichnung seiner Funktionen ist eine leicht veränderte Wortaufteilung.

Jedem der Teile war ein charakteristischer Buchstabe zugeordnet: w (dem Wort insgesamt), p (dem Präfix), i (dem Indikator), s (dem Vorzeichen), d (dem Dekrement), t (dem Tag) und a (dem Adreßteil).

\begin{picture}(400,130)


0 1 2 3   17 18 20 21   35
        Dekrement-Teil         Adress-Teil  
        (Zeiger aufs         (Zeiger auf Unter-  
        nächste Element)         liste oder Atom)  

\put(30,20){Indikator (Typinformation)} \put(210,20){Tag} \put(0,10){Vorzeichen (GC-Bit))} \put(20,0){Präfix} \end{picture}

\begin{center}Abb. 3. Wortstruktur der IBM/704 und die LISP-Interpretation [MCC58a]\end{center} Zu der ersten Klasse der Basisfunktionen gehörten die Extrahierungsfunktionen pre, int, sgn, dec, tag und add. Dazu kam eine Funktion, die nur ein bestimmtes Bit lieferte: bit, und eine, die ein beliebiges Segment aus dem Wort herauslöste: seg. Um ein Wort wieder zusammenzufügen gab es comb4(t,a, p, d) und comb5(t, a, s, i, d) sowie eine bitorientierte Funktion choice.

In der zweiten Klasse wurden die Funktionen cwr, cpr, csr, cir, edr, ctr und ear zusammengefaßt. Ihr Argument war eine 15-Bit-Adresse. Natürlich waren sie mit den Funktionen der ersten Klasse verwandt. So galt:

\begin{center}\tt add(ewr(j)) = car(j).\end{center}

Den Funktionen bit und seg entsprachen die Funktionen cbr und csgr.

Die Funktionen, die 15-Bit Quantitäten, d.h. Adressen, lieferten, konnten auf der linken Seite einer Zuweisung stehen, also das Ziel einer Zuweisung beschreiben. Der gleiche Effekt war durch Aufruf der Speicherfunktionen stwr, stpr, stsr, stir, stdr, sttr und star erreichbar. Jede dieser Funktionen hatte zwei Argumente: die Adresse (als Zahl) des Wortes, das gespeichert werden sollte und das zu speichernde Datum.

Die Konstruktionsfunktionen dieser Klasse arbeiteten ähnlich zu den FLPL-Funktionen XDWORDF und XLWORDF: Sie lösten ein oder zwei Wörter von der Freispeicherliste ab, verkürzten diese entsprechend und füllten das bzw. die Worte mit ihren Argumenten; consw hatte zum Argument ein ganzes Wort und füllte damit das freie aus der Freispeicherliste; consel hatte nur zweiArgumente und belegte mit ihnen Adreß- bzw. Dekrementteil, alle anderen Teilfelder belegte es mit 0; consls arbeitete fast genauso, belegte aber das Indikatorfeld mit 2 (eine Unterliste anzeigend); consfl schließlich holte zwei Worte aus der Freispeicherliste; das erste wurde ganz mit dem ersten Argument von consf gef\" ullt, das zweite mit einem Zeiger im Adreßteil auf dieses erste Wort und im Dekrement das zweite Argument. Die Adresse dieses zweiten Wortes, in dem der Indikator aufgestellt wurde, war das Ergebnis.

Die Klasse wurde komplettiert durch die Löschfunktion erase und die Zeigerbewegungsfunktionen point, mova, movd und movup.

Wir wollen die Ideen zur Implementation, die weitgehend an FLPF angelehnt waren, nicht analysieren, da allzuviel unklar war zu dieser Zeit. Viel interessanter ist dagegen der Gebrauch der funktionalen Argumente, da noch keine $\lambda$-Notation verwendet wurde.

Schon bei Erwähnung der Funktion maplist war aufgefallen, da\sssie drei Argumente haben sollte: Da als drittes Argument ein Ausdruck stehen sollte, mußte im zweiten Argument die lokale Variable bekannt gemacht werden. Dies kann schön in dem Beispielprogramm betrachtet werden. Übrigens erkennt man, da\ssder Atomtest durch die Frage: ``Ist der Indikator = 1 ?''erledigt werden sollte. {\tt

The P\=rogram is:
   function diff(J)
   diff = (ctr(J) = 1 $\rightarrow$ 0, car(J) = "x" $\rightarrow$ 1, car (J) 
= "plus" $\rightarrow$ consel("plus", maplist(cdr(J),K,diff(K))), car 
(J) = "times" $\rightarrow$ consel("plus", maplist (cdr(J),K, consel 
("times", mapist(cdr(J),L,(L = K $\rightarrow$ diff(L), L = K $\rightarrow$ 
copy (L)))))))
   return

}\begin{center}Abb. 4. Die Funktion diff für die Differentiation [MCC58a][App. I]\end{center}

Zweifellos kann man sich nur schwer vorstellen, da\ssdieses Programm lauffähig sein sollte. Aber das fühlte sicher auch McCarthy. Er dürfte so manche andere Variante versucht haben.

So hat höchstwahrscheinlich die Auseinandersetzung mit diesem Programm und seiner Implementation zur Aufnahme der $\lambda$-Notation in LISP geführt. Ob die Idee dazu von McCarthy allein kam, oder ob Rochester, Minsky oder Shannon, die als Professoren am MIT damals eng mit der Arbeit von McCarthy verbunden waren, hier einen Hinweis gaben, ist bisher nicht bekannt.

Es ist interessant, da\ssMcCarthys Argumente, die Definition von maplist so zu ändern, da\sssie nur noch zwei Argumente hat und eine Funktion als zweites Auftritt, hauptsächlich aus der Implementation abgeleitet sind: McCarthy scheint selbst versucht zu haben, ein Assemblerprogramm für maplist zu schreiben [MCC58b]. Dieses hatte zwei Schwächen: Einerseits wurde die Variable, die als 2. Argument auftrat, zu oft in dem Ausdruck (3. Argument) benötigt. Dies lie\sssich nicht bewältigen. Andererseits konnte die Variable sehr schlecht in die Aufruffolge für maplist integriert werden: Was sollte dann als Argument übergeben werden ?

Indem er sich vorstellte, da\ssdie Funktion, die als Argument auftauchte, als eine Instruktion zum Aufruf dieser Funktion in maplist verkörpert würde, war es McCarthy möglich, zu einer befriedigenden Definition und Implementierung zugelangen. Die in LISP geschriebene Definitionsgleichung lautete nun [MCC58b][S.2]:

\noindentmaplist(L,f) = (L = 0 $\rightarrow$ 0,1 $\rightarrow$ consls(f(L), maplist(cdr(L), f))).

Mit dieser neuen Form für das Funktional konnte die Differentiationsfunktion umgeschrieben werden: {\tt

 diff(L,V) = (car(L) = const $\rightarrow$ copy(CO), car(L) = var $\rightarrow$ (car
(cdr(L)) = V $\rightarrow$ copy(Cl), l $\rightarrow$ copy(CO)), car(L) = plus $\rightarrow$
consel(plus,maplist(cdr(L),$\lambda$(J,diff(car(J), V)))),car(L) = times $\rightarrow$
consel(plus,maplist(cdr(L),$\lambda$(J,consel(times,maplist(cdr(L),
$\lambda$(K,(J $\neq$ K $\rightarrow$ copy(car(K)), l $\rightarrow$ diff(car(K),V)))))))))

}\begin{center}Abb. 5. Die verbesserte Funktion diff mit $\lambda$-Notation[MCC58b]\end{center}

Man sieht, das inzwischen weitere Verbesserungen angebracht worden waren: Ansätze, um Variable von Konstanten zu unterscheiden, sind deutlich. Daneben sieht man, da\ss1 als Wahrheitswert true verwendet wird, demzufolge sicher 0 als false. Aus der obigen maplist-Definition kann auch abgelesen werden, da\ss0 auch das Listenende bezeichnete: Allerdings war die eine 0 eine Bit-Größe und die andere 0 eine 15-stellige Adresse. Aus Bequemlichkeitsgründen bei der Implementation wurden beide jedoch rasch durcheinandergewürfelt. Der Name der späteren LISP-Grundfunktion NULL resultierte ebenfalls aus diesen Implementationsdetails.

Zum Schlu\sssoll die Aufmerksamkeit noch auf ein kleines Detail gelenkt werden: In der Diskussion der Besonderheiten dieser Sprache zur Symbolmanipulation, wo McCarthy die algebraische Notation und ihre Vorteile, die Rekursion und ihre Implementation mit Hilfe von Push-Down-Listen (nach Newell, Shaw und Simon: wirkliche Listen!), die bedingten Ausdrücke und die funktionalenParameter abhandelt, wird auch kurz erwähnt, da\sssich Ausdrücke günstig durch Listen darstellen lassen. Dies wird nicht auf Datenausdrücke beschränkt [MCC58a][S.2]. Später (S.11) zeigt er, da\ssein funktionaler Ausdruck $f(e_{1}, ... , e_{n})$ durch den Satz {\tt (f, $e_{1}$, $...$, $e_{n}$)} dargestellt wird, und bemerkt, da\sser so als Listenstruktur verwirklicht werden könne. Gemeinsam mit der Angabe, da\ssauch der Compiler in der Sprache selbst notiert werden solle, kann daraus geschlußfolgert werden, da\ssschon erste Ideen für die Repräsentation von Programmen als Listendaten entwickelt worden waren.

Da die Programmiersprache, nun einigermaßen konkretisiert, für die Realisierung der Ideen beider Leiter des Projekts -- McCarthy hatte seine Vorstellungen einem Programm, das künstliche Intelligenz zeigen sollte, in seiner Arbeit vom Advice Taker [MCC58c] zu Papier gebracht -- notwendig war, begann man mit der Implementierung. Allerdings wußte niemand genau, wie ein Compiler zu schreiben sei, und das Beispiel FORTRAN war eher abschreckend, denn man hatte 30 Mannjahre dafür benötigt, und das war für jene Zeit ein unvorstellbar großer Aufwand.

Um Erfahrungen zu sammeln, begann man verschiedene Funktionen per Hand in die Assemblersprache umzusetzen. Dabei sollten Konventionen für Unterprogrammaufrufe, für Kellerspeicherarbeit und für die Speicherverwaltung erarbeitet werden. Diese Arbeit wurde hauptsächlich von den Programmieren K.Maling und S.B.Russell ausgeführt. Aber auch die Studenten, unter denen {\sc D.G.Bobrow, D.C.Luckham, D.M.R.Park} und R.K.Brayton sowie L.Hodes, L.Kleinrock und J.R.Slagle waren, hatten einen gewissen Anteil.

Bei der Handübersetzung der Einlese- und Ausgabefunktionen wurde praktisch eine externe Standardnotation für symbolische Ausdrücke geschaffen, in dem runde Klammern (parentheses) als Listenklammern\footnote{McCarthy ist sich heute nicht mehr sicher, ob diese spezielle Entscheidung nicht schon früher gefallen war [MCC74}] verwendet wurden und eine Präfixnotation, in der alle mathematischen Operatoren in einheitlicher syntaktischer Weise behandelt werden. So wird $a + 2b + c^{2}$ zu (PLUS A (TIMES 2 B) (EXP C 2)). Diese Notation wurde später ``Cambridge Polnisch'' genannt, um J.Lukasiewicz und W.V.Quine zu ehren.

Die externe Notation war relativ arm an Sonderzeichen auf Grund der beschränkten Zeichenmenge des IBM026-Lochers.

Die Programmiersprache jedoch, die etwa in dieser Zeit ihren Namen LISP bekam, hatte einen größeren Zeichenvorrat, da sie eingentlich nie abgelocht werden mußte, sondern nur für ``Papierprogramme'' verwendet wurde. Sie entsprach im Grunde genommen immer noch FORTRAN, nur konnte man bedingte Ausdrücke verwenden und ebenso die Listenverarbeitungsfunktionen und rekursiven Funktionen definieren. Um Listenkonstanten im Programm erwähnen zu können, schrieb man eckige Klammern (brackets), wenn man Argumente einer Funktion zusammenfassen wollte. Die später sogenannte M-Sprache [MCC62c] dürfte dem LISP Ende 1958 weitgehend entsprechen, allerdings hat der Terminus prog gefehlt. Über Deklarationsvorschriften ist nichts bekannt. {\small

 diff[s;v] =
        [atom[s] -> [eq[s;v] -> 1.0; T -> 0.0];
         eq[car[s]; PLUS] -> cons[PLUS;
                                  maplist[cdr[s];
                                          $\lambda$[[si]; diff[car[si]; v]]]];
         eq[car[s]; TIMES] -> cons[PLUS;
                                   maplist[cdr[s];
                                          $\lambda$[[si]; 
                                             cons[TIMES;
                                                  maplist[cdr[s];
                                                          $\lambda$[[sj];
                                                            [equal[si;sj] -> diff[car[sj]; v];
                                                              T -> car[sj]]]]]]]]]
a)
 pairmap[k; m; farg; z] =
  prog[[b];
    A   [null[k] -> return[conc[reverse[b]; z]]];
        b := cons[farg[car[k]; car[m]]; b];
        k := cdr[k];
        m := cdr[m];
        go[A]
b)

}\begin{center} Abb. 6. Zwei Beispiele für die M-Sprache mit prog.\end{center}

Als komplizierteste Probleme bei der Umsetzung der LISP-Programme in Assemblerprogramme entpuppten sich die Realisierung der rekursiven Funktionen und die Löschung unnötiger Listenstrukturen.

Die Organisation der rekursiven Funktionen (und überhaupt der Unterprogrammarbeit) war deshalb so wichtig, weil diese die grundlegende Begriffsbildung wurden. Man konnte bei der Lösung der hiermit verbundenen Probleme auf das Beispiel von IPL zurückgreifen. Allerdings schien die Implementierung der Kellerspeicher als Listen nicht geeignet zu sein, und McCarthy entschied, zur Beschleunigung lineare Folgen von Maschinenworten zu verwenden. Dachte man zunächst daran, jeder Funktion ihren privaten Keller zuzuordnen, so nahm man doch schnell davon Abstand. Der zentrale Kellerspeicher blieb bestehen.

Die Unterprogramm-Eintrittskonventionen wurden jetzt vollendet, so da\ssbeim Ansprung eines Unterprogramms einheitlich die benötigten temporären Register (Speicherworte) im Kellerspeicher gerettet wurden, um in dem Programm selbst zu Verfügung zu stehen. In jedem dieser Blöcke im Keller wurde später noch der Name der Funktion, die Größe des Blocks und seine Herkunft aus dem Speicher beschrieben.

In Entsprechung zu den Festlegungen beim Eintritt wurde auch das Verlassen der Unterprogramme vereinheitlicht.

Diese Arbeiten stellten durchaus Pionierleistungen dar, denn obwohl das Kellerprinzip bekannt war, wurde es für eine systematische Implementation noch nicht genutzt. E.W.Dijkstras Veröffentlichung über seine ALGOL-Implementation erfolgte erst 1960[DI60].

Die Löschung unnötiger Listenstrukturen erwies sich als schwer lösbares Problem. IPL hatte für diesen Zweck ein sehr komplexes System eingeführt. Listen waren im allgemeinen nur über eine bestimmte Variable erreichbar. Jedoch konnte man sie sich zum Gebrauch borgen. Wollte der Programmierer eine solche Listen dem Arbeitspeicher wieder zuführen, so mußte er sicher sein, da\sssie nirgends mehr ausgeborgt war.

Es gab einen expliziten Löschoperator. Für den Löschvorgang selbst scheinen externe Geräte benutzt worden zu sein [MCC74]. Um bei diesem Vorgang nur die Teile zu löschen, die nicht mehr gebraucht wurden, hatte man Verfügbarkeitsbits eingeführt. Nur die Teile, die zur Löschzeit wirklich frei verfügbar waren, wurden auch zum Löschen freigegeben. Das Problem, die Verfügbarkeit einer Teilstruktur zu bestimmen, wurde so zu einer wichtigen und komplizierten Aufgabe, weil sich diese Verfügbarkeit ständig änderte und weil das ``Ausgeborgtsein'' nicht einfach zu überschauen war.

In IPL-Programmen kam ein Verfügbarkeitsfehler häufig vor; Man sprach von einem Speicherplatz-Dieb (space thief), wenn wichtigen Listenstrukturen gelöscht waren. Oft rechnete solch ein Programm mit zerstörten Listenzellen noch lange Zeit, ehe es mit völlig verdorbenen Fehlermeldungen abbrach.

Zu jeder Zeit bot sich eine Idee von G.E.Collins [COL60,COL63]\footnote{Es ist noch nicht klar, ob diese 1958 bereits entwickelt war.} an, die Verfügbarkeit durch Referenzzähler zu bestimmen. Diese Zähler sind jedem Wort, das Teil einer Listenstruktur ist, zugeordnet, und enthalten die Anzahl der Bezugnahmen, die auf das betreffende Wort gemacht werden. Will man nun Teilstrukturen löschen, so werden nur die wirklich beseitigt, deren Referenzzähler gleich 0 ist. Kann man einen Teil löschen, dann werden alle Referenzzähler, auf die sich dieser Teil bezieht, um 1 verringert.

Die Verfolgung dieser Idee für LISP erwies sich als ungünstig auf der IBM704, denn diese Maschine besa\sszwar sechs freie Bits in jedem Wort, aber diese waren getrennt.

Die neue Idee war, da\ssder Programmierer sich um das Löschen nicht mehr kümmern sollte. Dies war zunächst die einfachste Lösung, da man noch keine Speicherprobleme hatte und so das Problem erst einmal weggeschoben war.

Erst 1959 erarbeitete man (wahrscheinlich McCarthy selbst) die Vorstellung von der dynamischen Speicherverwaltung und ihrem Kernstück, dem Regenerator (reclaimer). Nur wenn der Speicherplatz erschöpft ist, beginnt ein Prozeß, bei dem alle erreichbaren Worte bestimmt werden und die unerreichbaren in die Freispeicherliste gestellt werden. Dieser Vorgang wurde von den Programmierern als Abfallsammeln (Garbage Collection) bezeichnet, ein Begriff, der zunächst wegen seiner Vulgarit\" at in Veröffentlichungen nicht verwendbar schien (er wurde dann von den Rezensenten durch ``reclaimer'' ersetzt), sich aber inzwischen durchgesetzt hat.

Im Zusammenhang mit dem Garbage Collection mußte man bestimmen, welche Listenstrukturen erreichbar sein sollten. Da dazu jedenfalls alle diejenigen zu rechnen waren, die vorübergehend im Kellerspeicher aufgehoben worden waren, mußte man dafür sorgen, da\ssandere Informationen, die im Keller abgelagert worden waren, nicht als Zeiger in den Listenspeicher interpretierbar waren. So mußten ganze Zahlen und Gleitkommazahlen in einen Bereich der Konstanten umgelegt werden und mit Zeigern referiert werden. Allerdings scheinen die Zahlen zunächst als Listen von Ziffern dargestellt worden zu sein.

So war das Garbage Collection als Programm erfunden, ebenso seine Unterordnung als Teilprogramm von CONS. Später sorgte man dafür, da\ssdem Benutzer Ergebnisse des Garbage Collections als Speicherstatistiken zur Verfügung gestellt wurden.

Auf diese Art war nach und nach ein Programmsystem entstanden, das durch handübersetzte LISP-Funktionen erweiterbar war. Von den Programmen, die in dieses System eingebettet waren ist nur ein Programmsystem zur Behandlung elektrischer Netzwerke bekannt, das nach J.Moses [MOS71] das erste Vereinfachungsprogramm enthielt:[GOB59,ED59] und weiterhin Malings Differentiationsprogramm[MAL59].

Einige der Festlegungen sind für die Folgezeit ungünstig gewesen. Sicher gehört dazu die -- für die Implementation technisch günstige -- Idee, die Listen mit 0 abzuschließen und das Atom, das als Wahrheitswert für ``falsch'' verwendet wurde, damit zu indentifizieren (zunächst wurde sogar die 0 selbst dazu eingesetzt).Dieses Atom hie\ssNIL (bzw. wurde kurze Zeit später NIL genannt), aber die Frage nach NIL wird mit der Funktion NULL getätigt. ``Außer der Ermutigung pornographischer Programmierung hat die Zuordnung einer speziellen Bedeutung zur Adresse 0 in allen darauffolgenden Implementationen Schwierigkeiten gemacht.'' [MCC78a].

Eine Definition der Programmiersprache LISP existierte zu dieser Zeit allerdings noch nicht, da ein Compiler fehlte, der eine exakt festgelegte Syntax erzwungen hätte. Für die Übersetzung der Papierpogramme in die Assemblerform genügten grobe Festlegungen, und zur Not reichte ein Kommentar. In dieser Situation sollte ein Artikel entscheidend werden, den McCarthy Anfang 1959 zu schreibenbegann [MCC59b] und der Anfang 1960 in der Communications ACM erschien [MCC60c]. McCarthy wollte hier seine Auffassung darlegen, da\ssseine Sprache, wie sie damals war, genauso gut für die Theorie der Berechenbarkeit als Beschreibungsmittel geeignet sei, wie etwa der Apparat der Turing-Maschinen. Natürlich war sie auch praktischer, weil die wesentlichen Dinge viel schneller ausgeführt werden konnten (``...man konnte wirklich beweisen, da\sssie besser (neater) ist ... man konnte weniger komplizierte Beweise machen ...'')[MCC74].

Um zu zeigen, da\ssman mit LISP nicht nur die berechenbaren Funktionen viel einfacher beschreiben kann, sondern da\ssman auch den gleichen Funktionsumfang erhält, wählte McCarthy die Aufgabe, eine allgemeine (universelle) LISP-Funktionen zu schreiben und zu zeigen, da\sssie kürzer und verständlicher ist als die Beschreibung einer universellen Turing-Maschine. Eine universelle {\scTuring}-Maschine wird dadurch charakterisiert, da\sssie auf ihrem Eingabeband die Beschreibung einer anderen Turing-Maschine und Daten für diese bekommt und sie dann imitieren kann. Demnach mußte die universelle LISP-Funktion die Beschreibung von LISP-Funktionen als Datum akzeptieren und damit entsprechende Leistungen zeigen, d.h. also die Arbeit der betreffenden Funktionen ausführen können.

Zu diesem Zweck mußte eine Notation gefunden werden, in der alle LISP-Ausdrücke und LISP-Funktionen als symbolische Ausdrücke beschreibbar waren. Dies ist nicht so einfach, da die LISP-Funktionen Konstante symbolische Ausdrücke enthalten können, die sich durch nichts von den zu erzeugenden Beschreibungen unterscheiden. Durch Einf\" uhrung des Quotierens für solche konstante symbolische Ausdrücke wurde dieses Problem gemeistert, und McCarthy gelangte zu den bekannten Übersetzungsregeln [MCC60c][S.186f.]:

  1. Ist E ein S-Ausdruck, dann ist (QUOTE, E) dasÜbersetzungsresultat.

     

  2. Variable und Funktionsnamen, die durch Folgen von kleinen Buchstabendargestellt sind, werden übersetzt in die entsprechenden Folgen mit großen Buchstaben.

     

  3. Eine Form {\tt $f$($e_{1}$; $e_{2}$; ...; $e_{n}$)} wird in den Ausdruck {\tt ($f^{+}$, $e_{1}^{+}$, $e_{2}^{+}$, ..., $e_{n}^{+}$)} übersetzt (dabei zeigt der Index $+$ das Resultat des Übersetzungsvorgangs auf Teilausdrücke an).

     

  4. {\tt [$p_{1} \longrightarrow e_{1}$; ...; $p_{n} \longrightarrow e_{n}$]} wird in {\tt (COND ($p^{+}_{1}$, $e^{+}_{1}$) $...$ ($p^{+}_{n}$, $e^{+}-{1}$))} übersetzt.

     

  5. {\tt $\lambda$[[$x_{1}$, $...$, $x_{n}$]; $e$]} wird in {\tt (LAMBDA ($x^{+}_{1}$, $x^{+}_{2}$, $...$, $x^{+}_{n}$) $e^{+}$)} übersetzt.

     

  6. label[a;e] wird in {\tt(LABEL, $a^{+}$, $e^{+}$)}übersetzt.

Der Operator label erschien notwendig, um auch rekursive Funktionen bezeichnen zu können. Als man diesbezügliche Schwierigkeiten mit dem $\lambda$-Kalkül zu haben glaubte, schlug Rochester diese Änderung vor. Allerdings wäre auch ohne gegangen, nämlich mit einer Konstruktion, die dem Churchschen paradoxen Kombinator Y entspricht.

Natürlich war die Tragweite des Entschlusses, Daten und Programme in derselben Notation zu schreiben, nicht von Anfang an klar. Die der universalen Turing-Maschine äquivalente Funktion EVAL\footnote{D.Park behauptet, da\ssim November 1958, als er zu McCarthys Gruppe stieß, APPYL-EVAL bereits arbeitete. Es mag sein, da\ssdas arbeitende System mehr die damalige Gesamheit der handübersetzten Funktionen war.} war nur als theoretisches Vehikel gedacht, um einen Beweis führen zu können, der Übersetzungsproze\ssebenfalls.

Die Niederschrift des Artikels und die Formulierung der Ausdrücke auswertenden Funktion hatte jedoch eine Reihe von unerwarteten Folgen. Diese wurden hauptsächlich ausgelöst durch die zufällige Entscheidung von Russell, die Funktion EVAL in ein Assemblerprogramm überzuführen. ``Steve Russel sagte, `gib mal her, warum sollte ich nicht dieses EVAL programmieren...?', doch ich antwortete ihm, `Ho ho, du verwechselst Theorie und Praxis, denn dieses EVAL ist zum Lesen gedacht und nicht fürs Rechnen...' Doch erging und tat es...'' [MCC74].

Zu dieser Zeit, als McCarthy an seinem Artikel arbeitete, war das Compilerprojekt noch gar nicht richtig begonnen worden. In der Situation ohne Compiler war die implementierte EVAL-Funktion als Interpreter ein regelrechter Lückenfüller[MCC76]. Da sie aber die Möglichkeit bot, die LISP-Programme nach einer einfachen Umformung an das laufende System anzuschließen, wurde sie auch benutzt.

Die Benutzung führte dazu, da\ssman die bisher inkonsequent aus Ausdrücken und Anweisungen aufgebauten Programme ganz streng zu verschachtelten Ausdrücken umformen mußte. Nun wurde es erst erforderlich, die ``Funktion''prog einzuführen, um doch einen gewissen Teil des gewohnten FORTRAN zu retten. LISP ist erst eine Ausdruckssprache, seit es die implementierte EVAL-Funktion gab.

Richtig ernst genommen wurde auch der Interpreter noch nicht. Einige der ersten Implementationen von LISP (mindestens auf der Q-32) verzichteten ganz auf die Interpretierung, ohne sich damit von LISP entfernen zu müssen. Erst als LISP in ein Time-Sharing-System eingebettet war, dürften alle Vorteile der Verarbeitung durch einen Einlesen-Interpretieren-Ausgeben-Zyklus klar geworden sein.

``Die unerwartete Existenz eines Interpreters führte zur Kaltstellung der Form der Sprache'', schreibt McCarthy [MCC78a], um unerwünschte Folgen der EVAL-Implementierung zu charakterisieren, ``und einige der Entscheidungen, die eher leichten Herzens für die Veröffentlichung von `recursive functions...'gefällt worden waren, erwiesen sich später als unglücklich. Diese schließen die COND-Notation für bedingte Ausdrücke ein, die zu einer unnötigen Menge von Klammern führt...''

``Ein Grund für die anfängliche Bereitschaft, mit den Nachteilen der internen Form von LISP zu leben, war, da\sswir immer noch hofften, Programme als M-Ausdrücke zu schreiben. Das Projekt, M-Ausdrücke präzise zu definieren und sie zu compilieren oder sie mindestens in S-Ausdrücke zu übersetzen, war weder beendet noch explizit aufgegeben worden. Es war nur in die unbestimmte Zukunft verschoben, doch dann erschien eine neue Generation von Programmierern, die die interne Notation jeder FORTRAN- oder ALGOL-ähnlichen vorzog...''[MCC78a].

So ganz direkt war der Weg von der Veröffentlichung zur Implementierung allerdings nicht gewesen. Bei der Übersetzung und Testung müssen Russell und Maling noch eine Reihe von Fehlern beseitigt haben. Dem heutigen Leser, wenn er einige Kenntnis von LISP hat, springen diese natürlich ins Auge. Es ist einigermaßen kurios, da\ssC.R.Jordan 1973 eine kritische Veröffentlichung über die Fehler dieser ersten EVAL-Funktion schrieb [JO73].

Neben notationellen Fehlern (Benutzung undefinierter Funktionen und unklaren Zeichen (z.B. = -- in [MCC59d] deutlicher als in [MCC60c]) findet sich die unerwünschte Eigenschaft, da\ssbei jeder Bestimmung des Funktionsnamens in der Assoziationsliste (wo die lokalen Variablenbedeutungen abgelagert sind) die Argumente ausgewertet werden. Da\sseine Funktion errechnet werden könnte, ist völlig ignoriert worden. Diese Fehler sind in den später veröffentlichten EVAL-APPLY-Funktionen beseitigt worden [MCC62c,MCC63e].

Auch für McCarthys wissenschaftliche Interessen war der Artikel über die universelle LISP-Funktion folgenreich. Zunächst wurde sein Interesse für die Theorie der rekursiven Funktionen wesentlich erhöht, und er beschäftigte sich weiter mit der Frage, wie man auf seinem LISP-Kalkül eine brauchbare Theorie der Berechenbarkeit aufbauen könnte. Beim Nachdenken darüber, was eine solche Theorie zu leisten hätte, kam er zum Problem des Beweisens von Programmeigenschaften usw., wie er dies 1963 in seiner Grundsatzarbeit [MCC63a] darlegte. In einer frühen Form äußerte er sich Anfang 1961 zu diesem Thema [MCC61b].

Anderseits hatte er, wie es ihm später klar werden mußte, nicht nur eine universelle LISP-Funktion geschrieben, sondern gleichzeitig die Semantik (der ihm noch gar nicht bekannten) Sprache LISP beschrieben. Dijkstras Urteil[DI72] über die LISP-Definition ``als kuriose Mischung dessen, was die Sprache bedeutet und davon, wie der Mechanismus arbeitet'', trifft die Sache genau, obwohl sie ins Leere zielt: Die Definition war nicht beabsichtigt!

Sicher ist, da\ssMcCarthy später von seinem Ansatz, LISP zu beschreiben, ausging, um Vorschläge für die Definition der Semantik von Programmiersprachen zu machen [MCC64] und da\ssdiese Vorschläge ungemein einflußreich waren. Die Wiener Definitionssprache ist ein Abkömmling seiner Ideen.

Um es zusammenzufassen: Ganz plötzlich und unabsichtlich war durch die Implementierung von EVAL eine zweite Sprachform neben der bisherigen Sprache LISP entstanden. Vorerst nannte man die Sprache nach den symbolischen Ausdrücken (den LISP-Daten) S-Sprache. Die ältere Form bekam den Namen M-Sprache, weil man in ihr über die Arbeit in der S-Sprache (z.B. den Auswertungsmechanismus) sprechen konnte (M von meta). Obwohl die M-Sprache bald nur noch zum Entwerfen der Programme (wenn überhaupt) benutzt wurde und nicht einmal ein Übersetzungsprogramm von M-Sprache zu S-Sprache geschrieben wurde (dies kann an der Nichtverfügbarkeit eines Geräts mit dem erforderlichen Zeichensatz gelegen haben), verschwand sie nie ganz. McCarthy selbst hat offenbar immer die M-Sprache bevorzugt.J.R.Allens Buch über LISP [ALL78] verwendet nur die M-Sprache und nennt die S-Sprache eine ``Repräsentationsform''. E.Sandewall [SAN75b] betont die Unabhängigkeit der externen Notationsweise von der internen Darstellung, die die S-Ausdrücke wiederspiegeln. Dennoch ist LISP heute mit der S-Sprache von damals identisch.

Mit der Fertigstellung des Übersetzers der EVAL-Funktion und ihrer Verbesserung ist das erste LISP-System so weit gediehen, da\sses direkt benutzungsfähig war. Durch die Einfügung der Funktionen APPLY, EVAL, EVCON und EVLIS [MCC60c][S.189] in das vorhandene Programmiersystem war so ein interpreterorientiertes System geschaffen, dessen Vorteile durch McCarthys gleichzeitige Arbeiten auf dem Gebiete der Time-Sharing-Systeme sichtbar wurden.

Übrigens hatte sich so ziemlich am Anfang ein schöner Fehler [ALL78] in das System eingeschlichen, der die Form der Sprache wesentlicht beeinflußte: Das Druckprogramm vergaß, die Kommata zu drucken, oder lieferte ein nicht druckbares Zeichen. Jedenfalls stellte man fest, da\ssdie Listen ohne die Kommata viel besser lesbar waren. So wurde das Druckprogramm belassen und die Notation geändert.

Lange Zeit nahm das Komma eine kuriose Stellung ein: Jedes LISP Programm konnte auch mit Kommata notiert werden, und üblicherweise hätten die LISP-Systeme auch richtig eingelesen. Aber niemand benutzte das Komma in dieser Weise. Weil das Komma aber dadurch zum Syntaxzeichen wurde, führte es ein wahres Schattendasein: Falsche Benutzung hätte syntaktische Fehler ausgelöst und richtige Benutzung war nicht üblich! Es war gewissermaßen ein Unzeichen. Erst die Idee, durch ein Backquote (`) aufzubauende Strukturen zielorientiert zu beschreiben und ihnen einzubauende variable Bestandteile zu kennzeichnen, hat das Komma aus seinem Dornröschenschlaf erlöst.

Im Grund läßt sich kein genaues Datum für die Fertigstellung des ersten LISP-Systems angeben. Wenn wir von Parks Erinnerung ausgehen, da\sseine frühe EVAL-APPLY-Version schon im November gelaufen war, dann dürfte schrittweise Erweiterung, Verbesserung und Überarbeitung des Systems, einzelner Funktionen oder Veränderung der Atomstrukturen immer ein mit weniger werdenden Einschränkungen benutzbares Programmiersystem vorhanden gewesen sein.

Die Studenten D.J.Edwards, S.H.Goldberg, P.Markstein und C.S.Rubenstein haben sicher schon Anfang 1959 mit ihren Arbeiten zur Benutzung der Formelmanipulation für die Berechnung elektrischer Schaltkreise begonnen. Leider enthält der Fortschrittsbericht vom Anfang Januar 1959 [MCC59b] keinerlei Hinweise.

Im April ist der Zustand aber schon sehr entwickelt. Es wird eine ganze Serie von Programmen explizit erwähnt, die in LISP geschrieben wurden. Allerdings scheint man daneben auch noch die Assemblersprache genutzt zu haben (so etwa vermutlich für das von Shannon, McCarthy, Abrahams und Kleinrock in Erarbeitung befindliche Sprachprogramm). ``Der gegenwärtige Status des Systems kann wie folgt zusammengefaßt werden:

  1. (a) Die Quellsprache ist entwickelt worden und wurde in verschiedenenMemoranda der AI-Gruppe beschrieben.

     

  2. (b) 20 nützliche Unterprogramme sind in LISP programmiert, in {\txSAP} (Assemblersprache der IBM704) handübersetzt und ausgetestet worden. Darunter sind Routinen für das Einlesen und Ausgeben von Listenstrukturen.

     

  3. (c) Eine Routine zum Differenzieren elementarer Funktionen wurdegeschrieben. Eine einfache Version ist ausgetestet und eine kompliziertere Version, die jede Funktion differenzieren kann, wenn eine Formel für ihren Gradienten gegeben ist, ist beinahe ausgetestet.

     

  4. (d) Eine universelle Funktion apply ist in LISP geschrieben,handübersetzt und ausgetestet worden. Wenn ein symbolischer Ausdruck für eine LISP-Funktion und eine Liste von Argumenten gegeben sind, dann berechnet apply das Resultat der Anwendung der Funktion aufdie Argumente. apply kann als Interpreter für das Systemdienen, und es wird für das Austesten von LISP-Programmen verwendet, bevor diese in die Maschinensprache übersetzt werden.

     

  5. (e) Die Arbeit an einem Compiler ist begonnen worden. Ein Entwurfist in LISP geschrieben und wird diskutiert, bevor er in die Maschinensprache übersetzt oder mittels apply ausgetestetwird.

     

  6. (f) Das LISP-Programmiersystem basiert ... mathematisch auf einerMethode, die allgemeinen rekursiven Funktionen von symbolischen Ausdrükken zu generieren''[MCC59c][S.122].

In dem Report selbst, der ja der Entwurf für die Arbeit ``Recursive functions...''[MCC60c] darstellt, erwähnt McCarthy zwei Compilerversionen und das Gargabe Collection.

Bis zum Sommer 1959 schlossen Edwards und Rubenstein ihre Arbeiten für den Grad des Bachelor of Science ab; im Herbst beendeteGoldberg seine Masters Thesis.

Auf dem Jahrestreffen der ACM, Anfang September 1959, stellte McCarthy seine Programmiersprache LISP zum erstenmal der Öffentlichkeit vor [MCC59g]. Über das Echo ist nichts bekannt. Eine ähnliche Vorführung des über eine Schreibmaschine interaktiv benutzbaren Systems (das Flexowritersystem von Luckham und Edwards) wird von McCarthy in [MCC78a] sehr humorvoll beschrieben.

Edwards blieb nach seinem Abschlu\ssam MIT und nahm ab September 1959den Platz von Maling ein, der ab 1960 in den Vierteljahresberichten nicht mehr als Gruppenmitglied erwähnt wird. In dieser Zeit begann McCarthy an einem Manual für LISP zu arbeiten, wurde aber nicht damit fertig [MCC59f].

Die Zeit bis Anfang 1960, wo fast gleichzeitig der Artikel ``Recursive functions...''[MCC&=c] und das LISP1 Manual [MCC60b] erschienen, sowie mit der Arbeit an der IBM709 begonnen wurde, war zum guten Teil ausgefüllt mit der Arbeit am Compiler und der Lösung des Problems mit den freien Variablen.

Brayton hatte, unterstützt von Maling und Park, den Compiler schließlich so weit, da\sser weitgehend fehlerfrei arbeitete. Üblicherweise werden Beschleunigungen um das 60-fache oder Zahlen wie: Laufzeit -- interpretativ 30 Minuten, compiliert 10 Sekunden, angegeben. Grob charakterisiert, kann der Compiler als einerseits zu den späteren Programmen gleicher Art sehr ähnlich (er war ja das Vorbild!), aber auch andererseits als verschieden zu ihnen bezeichnet werden.

Zum einen produzierte der Compiler bereits eine Liste von symbolischen Code -- in ``LISP Assembler'' (LAP). Anschließend wurde dieses Programm assembliert und als neue Maschinenfunktionen dem System hinzugefügt. Viele der dazu erforderlichen Programmteile sind in den späteren Compilern entweder direkt übernommen oder durch Umschreiben verändert worden.

Zum zweiten aber war der produzierte Code in seiner Art sehr verschieden von dem durch spätere Compiler erzeugten Code: Für lokale Variablen wurden Plätze durch GENSYM erzeugt und am Programmende angehängt. Rekursive Funktionen mußten diese lokalen Variablen erst explizit in der Keller befördern, bevor sie mit ihrer Arbeit beginnen konnten. Da das Befehlsformat nicht wie später aus Befehl und Operanden bestand, sondern ein Element für Marken freigehalten wurde, traten keinerlei Atome innerhalb der LAP-Code-Ebene auf.

Um zu wirkungsvollen Programmen zu kommen, wurden die Funktionen CAR, CDR, CONS und NULL, ``offen'' übersetzt\footnote{Hinzu kam möglicherweise auch ATOM}.. Dies galt natürlich für alle Spezialformen (PROG, GO, RETURN, COND).{\small

COMPILE 
(((LABEL, MEMLIS,(LAMBDA, (X, Y), (PROG, (M1),(SETQ, M1,Y), M2, 
(COND,((NULL, M1), (RETURN, F)), ((EQUAL, (CAR, M1), X),
(RETURN, T))), (SETQ, M1, (CDR, M1)), (GO, M2)))))) 
(MEMLIS, BSS, 0) 
( ,SXD, G0001, 4)            save index Register 4 
( , STO, G0002)              store x 
( , STQ, G0003)              store y 
( , CLA, G0003) 
( , STO, G0007)              set m1 = y 
(GOOO6, BSS, 0)              location M2 
( , CLA, G0007) 
( , TNZ, G0008)              to G0008 if null[M1] = F, or 
( , CLA, $ZERO)              return with AC = F if null M1 = T 
( , TRA, G0005)
(GOOO8, BSS, 0) 
( , LDX, G0007, 4) 
( , CLA, 0, 4) 
( , PAX, 0, 4)               car[M1] 
( , SXD, G0011, 4) 
( , LDQ, G0002)              x 
( , CLA, G0011)              car[M1] 
( , TSX, EQUAL, 4) 
( , STO, G00010)             result of equal test (note that the 
( , CLA, G00010)             compiler stores everything it computes) 
( , TZE, G0009)              transfer if car[M1] =x
( , CLA, $ONE)               otherwise return with AC = T 
( , TRA, G0005) 
(G0009, BSS, 0) 
( , LDX, G0007, 4) 
( , CLA, 0, 4) 
( , PDX, 0, 4)               cdr[M1]
( , SXD, G0007, 4)           set M1 = cdr[M1]
( , TRA, G0006) 
(G0005, BSS, 0) 
( , STO, G0004)              answer (true (one) or false (zero)) 
( , CLA, G0004) 
( , LXD, G0001, 4)           restore original index Register 4 
( , TRA, 1, 4)               return 
END OF APPLY, VALUE IS ...  
(MEMLIS)

}

\begin{center}Abb. 7. Compilierung von MEMLIS in LISP1 ([MCC60c][S.58,59]\end{center}

Auch das Variablenproblem wurde in dieser Zeit gelöst. Einer der ersten großen Anwender des LISP-Systems, Slagle, stie\ssauf Unstimmigkeiten im Verlauf der Programmierung für sein Integrationsprogramm. Er arbeitete mit großer Intensität, wie McCarthy [MCC76] sich errinnert, und bemühte sich um effiziente Lösungen für die Teilfunktionen. Dazu verwendete er in einem Fall funktionale Argumente und die inzwischen eingebaute Möglichkeit, statt Funktionsnamen Variable und beliebige Ausdrücke in funktionaler Stellung zu notieren (``... dies ist logisch unnormal, und ich lehnte diesen Gebrauch ab. Ich glaube aber, mancher benutzte es doch.'' [MCC76])

Slagle versuchte eine Funktion zu schreiben, die testen sollte, ob ein gegebenes Prädikat von allen Teilen eines S-Ausdrucks erfüllt würde. Er schrieb das ``... in einer netten rekursiven Art mit Funktionen von Funktionen als Argumente, aber es arbeitete nicht. So beschwerte er sich natürlich. Ich verstand diese Beschwerde niemals allzu gut und sagte nur, `Oh, es mu\ssirgendwo ein Fehler versteckt sein'. Steve Russell und Dan Edwards behaupteten, da\sseshiermit fundamentale Schwierigkeiten gäbe, doch ich glaubte es nicht und fordete sie auf, den Fehler zu finden.'' [MCC74]

Irgend jemand, jedenfalls unter Beteiligung von Russell und Edwards (Park weist auf P.Fischer hin [MCC78a]), bemerkte dann als Ursache dieses Problems die Konflikte zwischen den Werten der globalen bzw. freien Variablen bei der Funktionsdefinition und ihren Werten beim Aufruf der Funktion. Diese Konflikte treten im Normalfall nicht auf, weil alle Funktionen in einem Grundniveau definiert werden. Da $\lambda$-Ausdrücke aber auch Funktionen darstellen, kann die Verwendung von globalen Variablen in solchen $\lambda$-Ausdrücken problematisch werden, wenn sie über ein funktionales Argument oder ein Auswertungsergebnis aus der Umgebung transportiert werden, in die sie ursprünglich eingepaßt waren. Ähnliche Probleme traten wenig später in ALGOL60-Compilern auf (most recent error).

Um die Schwierigkeiten zu beseitigen, wurde FUNARG eingeführt (diese Lösung entspricht praktisch der Einführung von dynamischer und statischer Kette in ALGOL60 [BERR70]).

``Man versuchte, es mir zu erklären, aber ich war zerstreut oder jedenfalls abgelenkt und nicht aufmerksam, so da\ssich zunächst wirklich nicht begriff, was das FUNARG-Ding machte, sondern erst einige Jahre später. Aber dann wurde bekannt, da\ssdieselbe Art von Schwierigkeiten auch in ALGOL60 auftauchten, und zu dieser Zeit war die LISP-Lösung dafür, diejenige, die Steve Russell und Dan Edwards einfach ausgekocht hatten, um den Fehler zu beseitigen, eine umfassendere (more comprehensive) Lösung dieses Problems als jene, die zur gleichen Zeit in ALGOL-Compilern existierte'' [MCC74].

Inzwischen hat sich allerdings gezeigt, da\ssdie Lösung des Problems eherhalbherzig gewesen ist. Man hat seinerzeit das Problem unterschätzt und eine Brücke um den ``Fehler'' gebaut (ein patch). Die Lösung war zwar korrekt,man hätte aber in die Sprache eingreifen müssen und die Notation und Behandlung\footnote{die ja gar nicht dem McCarthyschen Übersetzungsprozeßentsprach!} von Funktionen (insbesondere der mit $\lambda$ beschriebenen) korrigieren müssen. Man glaubte, da\ssdie Fehlersituation nur selten aufträte, weil man meistFunktionen benennt. Auf dieses Unverständnis deutet schon die Tatsache, da\ssmehrere Erläuterungen des Problems Slagles Funktion verwenden, um ein praktisches Beispiel zu haben. Ebenso bezeichnend ist, da\ssdiese Demostrationen fehlerhaft sind (obwohl allerdings der entscheidende Punkt jeweils richtig herausgearbeitet wird); Fehler deuten aber das Nichtbegreifen an, wozu eine solche Funktion wohl nützlich sein könnte [SAU64a,MCC78a].

Viele Jahre lang wurde FUNARG nur im Ausnahmefall eingesetzt. Die Verwendungvon unbenannten Funktionen galt allenfalls als Notationstrick, um sauberer funktions-orientiert zu programmieren. Dementsprechend haben sich die Implementatoren schnell von dem exotisch erscheinenden Sprachelement getrennt, als es Implementationsentscheidungen im Wege stand. Mit der Zeit schlich sich bei den Programmierern die Meinung ein, FUNARG sei überflüssig -- und damit die statische Semantik der Programmvariablen --und statt dessen basiere LISP auf der dynamischen Semantik.

Die schwerer verständliche Semantik wurde akzeptiert, weil damit verbunden einige Vorteile eingehandelt werden konnten: Statt Funktionen, die gemeinsame Variablen benutzen, in Baumstrukturen zu notieren und dadurch die Gültigkeitsbereiche dieser Variablen explizit zu machen, arbeitet(e) man lieber mit linearen Dateien von Funktionen. Dieser meistgeübte Programmierstil ist mehr auf unabhängige Funktionen gerichtet (allenfalls globale Variablen werden als ``schädlich'' betrachtet). Man definiert eine Menge von Funktionen, die gleichberechtigt nebeneinanderstehen. Die Unterordnung wird durch Übergabe der Kontrolle zur Laufzeit hergestellt; die Variablenbereiche sind so weit wie möglich getrennt und weitgehend lokal; echt globale Variable werden selten benutzt.

Hinzukommt weiterhin, da\ssdiese Interpreter-orientierte Sicht die Programmvariablendichter an die LISP-Symbole assoziiert -- die Namen der Variablen bleiben wichtig. Ein während des Programmablaufs erzeugter Term (oder ein Teilprogramm) kann im Laufe seiner Auswertung unter Bezugnahme auf die dynamisch vorhandenen Variablenbelegungen verarbeitet werden.

In gewissem Sinne ist dieser Programmierstil praktisch und überschaubar, und man kann ihn mit vielen Forderungen, die die moderne Programmiermethodik aufstellt, in Einklang bringen. Problematisch war nur, da\ssin der großen Mehrzahl derLISP-Systeme ein Unterschied zwischen Compiler und Interpreter bestand: Arbeitete der Interpreter mit der dynamischen Semantik, so bezogen sich Compiler normalerweise auf die statische: Gerade die Arbeit mit den Programmvariablen wird verändert vom Zugriff auf die Wertzelle zu einem Zugriff auf den Argumentkeller.

Um 1970 führten J.Weizenbaum und auf ihm aufbauend Moses aus, daßhinter dem Problem in Wirklichkeit die inkorrekte Implementierung des $\lambda$-Kalküls stand. Durch Sandewall erstmals herausgestellt und durch Bobrowund B.L.Wegbreit...

Eines der wenigen Systeme, die sich um die Übereinstimmung von Interpreter und Compiler bemühten war InterLISP. Allerdings versuchte man den Weg, die dynamische Semantik zu realisieren. Doch konnte der Programmierer mittels zusätzlichem notationellen Aufwand eine das FUNARG realisierende aufwendige Implementierung verwenden. Erst im Gefolge von SCHEME ist vielen LISP-Programmierern klar geworden, welche Möglichkeiten die korrekte statische Semantik bietet.

Das LISP1 Programmers Manual (datiert mit dem 1.3.1960) verfaßte P.A.Fox, die im September 1959 zu McCarthys Gruppe gestoßen war. Ein durchaus interessantes System wird darin beschrieben. Es umfaßte zu dieser Zeit etwa 90 Funktionen, von denen einige höchst eigenartig und speziell waren (wie die so unverständliche Funktionen CP1 in LISP1.5), andere aus Edwards' und Goldbergs Arbeit stammten. So gab es Funktionenzum Vereinfachen, Differenzieren, Multiplizieren von Matrizen und für andere Matrizenmanipulationen, die wahrscheinlich im Rahmen der Arbeiten in Assembler umgesetzt worden waren und als Systemteile überlebt hatten.

Ein wichtiger Teil des Systems war das schon erwähnte Flexowriter-System, das auf der Basis einer das Time-Sharing vorwegnehmenden Idee (time stealing) interaktive Arbeit ermöglichte.

Es lag nun ein System vor, dessen Erarbeitung durch ein fehlendes Konzept nur langsam hatte vorangehen können [MCC76]. Dieintellektuelle Führung lag ganz in den Händen von McCarthyund Minsky; die eigentliche Programmierarbeit wurde von {\scRussell} und Maling (später Edwards) ausgeführt. Weiterhin waren ander ersten Implementation Hodes, Luckhamund Park beteiligt. Von diesen kann nur Malingein konkretes Objekt, die Ein- und Ausgabenprogramme zugeordnet werden. Die Arbeit von Brayton und Park am Compiler ist schonmehrfach erwähnt wo rden.

Zu der Arbeitsatmosphäre jeder Zeit liegt ein Bereich von Abrahams [AB76] vor: ``Das ursprüngliche Systemwurde von zwei angestellten Programmierern, Steve Russell und Dan Edwards\footnote{der erst ab September angestellt wurde -- H.S.}, entwickelt, zuzüglich einer Anzahl von Graduatestudenten, deren Namen im LISP1.5-Manual angeführt sind. Wir alle arbeiten in einem großen Raum, der im selben Haus war, wie die IBM 704. Hier waren auch die Projektbesprechungen, die einmal in der Woche stattfanden. Unser Zimmer lag direkt neben den Arbeitsräumen von M.Minsky und J.McCarthy. So begann das Treffenimmer damit, da\ssJ.McCarthy durch die Verbindungstüreintraten. Die erste Implementation wuchs so ziemlich holterdiepolter, und es dauerte eine ganze Zeit, bis die Anstrengungen einigermaßen koordiniert waren. Die Maschinenmöglichkeiten waren keine allzu guten, und LISP-Jobs brauchten eine Menge Zeit. Ein bestimmter Standardlauf dauerte immer ein wenig mehr als 5 Minuten, und deshalb hatten Steve und Dan einen Standardtrick: Sie bestellten die Maschine für einen Anwesenheitstest, der auf 5 Minuten begrenzt war. Zum Schlu\ssgelang es ihnen immer wieder, den Operator dazu zu bewegen,ihnen noch eine extra Minute zuzubilligen, von der sie natürlich von vornherein wußten, da\sssie nötig sein würde.''

Auch McCarthy erwähnt die fehlende Organisation [MCC76]:``Die Atmosphäre war zu locker zu Anfang, zum Teil, weil das Projekt selbst eine informale Existenz hatte (es war nie ein offizieller Start für das MIT Artificial Intelligence Project gegeben worden). Es gab keinen geschrieben Vorschlag für seinen Beginn, und alle Beteiligten wurden vom MIT Rechenzentrum und vom MIT Forschungszentrum für Elektronik (R.L.E.) unterstützt (bzw. waren dort angestellt). Die einzigen wirklichen Projektleute waren die Sekretärin (M.B.Webber) und die Programmierer und unser einziges Gerät ein Lochstreifenlocher. Verlor jemand das Interesse an der Arbeit, so wechselte er einfach zu einer neuen Beschäftigung.''

Die Studenten waren hauptsächlich Nutzer des Systems. Die Arbeiten von Goldberg [GOB59] zur Berechnung elektrischer Netzwerkeund von Edwards [ED59], der Resultate Goldbergsbenutzte, waren schon erwähnt worden. Der von Goldberg erarbeitete arithmetischer Vereinfacher ist vonden anderen Studenten, z.B. von Rubenstein [RUB59] undMarkstein [MCC59c], benutzt worden und in der Arbeit vonT.P.Hart [HART61] weiterentwickelt worden. Moses[MOS71] gibt an, da\ssGoldbergs Programm noch inAssemblersprache geschrieben war und als das erste existierende Vereinfachungspogramm ausgesehen werden kann. Bekannt ist ferner, da\ssim Integrationspogramm von Slagle dieser Vereinfacherbenutzt wurde [SL61]. Das Differentiationsprogramm von Maling[MAL59] ist ebenfalls schon erwähnt worden.

Als weitere Hauptaktivität darf die Überprüfung mathematischer Beweise angesehen werden, mit der sich McCarthy [MCC61a], {\scAbrahams} [AB3,64] sowie Bobrow, Maling und Park[MCC59c] beschäftigten. Daneben wurde noch über automatischeBeweisgenerierung gearbeitet; Bobrow und Raphaelbeschäftigten sich mit der Verarbeitung der natürlichen Sprache und einfachen Frage-Antwort-System [BO63b, RA63].Weitere Projekte waren: dieEntwicklung einer mechanischen Hand (Bobrow, Minsky und {\scShannon}), Schachprogramme (Abrahams, Kleinrock, McCarthy undShannon) und der Advice Taker (McCarthy, Minsky, Russell[MCC59b, c, 60a]).

Aus diesen Aktivitäten erwuchsen für die Studenten Promotionsarbeiten, die zwischen 1961 und 1963 verteidigt wurden.

Es fällt auf, da\sskeiner der Studenten die durch McCarthyArbeit aufgeworfenen theoretischen Probleme in der rekursiven Funktionentheorie oder der Theorie der Berechenbarkeit anging. Ebenso merkwürdig ist, da\ssauf dem LISP1-Manual verzeichneten Studentenüberhaupt nicht zur Promotion bezüglich LISP oder unter Anwendung von LISP kamen.

Dazu schreibt Park [PAR78]: ``Ich denke, da\ssMcCarthy,während er uns darin überlegen war, die Bedeutung der Sache einzuschätzen, ... , selbst genauso wie jeder andere überrascht war, da\sseine Sache von einer derartigen allgemeinenAuswirkung auf die Informatik entstanden war. LISP machte, da\ssalles einfach aussah. Paradoxerweise sahen für uns, die wirnach Forschungsgegenständen Ausschau hielten, in gewisse Sinne die Sachen zu einfach aus. McCarthy begann einen guten Teil der theoretischen Bedeutung in seiner Arbeit über die ``Mathematische Theorie der Berechnung'' zu zeigen -- aber er mußte dies fast allein tun. Der Rest von uns, insbesondere ich, hat die Botschaft viel langsamer erfaßt. Keiner der Forschungsstudenten, die als Koautoren des LISP1 genannt sind, begann eine Doktorarbeit, bei der Rechner benutzt wurden oder deren Thema Programmierung war. Ich selbst, der ich mich über LISP erregte und mit unberechtigtem Zorn McCarthy anfängliche Arbeit an seiner Theorie der Berechnung zusah, die mir viel zu schlicht erschien, als da\sssich ein so intellektuellambitionierter Student wie ich damit befassen sollte, ich endete bei einer Doktorarbeit in mathematischer Logik...''.

Anfang 1960 war die Implementation des LISP-Systems für die IBM709 begonnen worden, wie McCarthy in [MCC60c] berichtet. In derZeit danach schied ein guter Teil der Studenten aus, und andere, unter ihnen Hart und M.I.Levin, kamen und beteiligtensich an der Arbeit. Irgendwann wurde die IBM709 durch eine IBM7090 ersetzt, und Mitte 1962 war LISP durch so viele Verbesserungen gelaufen, da\ssein neues Manual erforderlich wurde. Levin hat eserarbeitet. Es ist mit dem 17. 8. 1962 fertiggestellt worden und wurde mit ``LISP1.5 Programmers Manual'' überschrieben.

Die Unterschiede zwischen LISP1 und LISP1.5 können wie folgt beschrieben werden:

  1. {\bf Unterschiede bei den Datenstrukturen}
    1. LISP1 erlaubte keine ganzen Zahlen, sondern nur Gleitkommazahlen. Diese waren ähnlich wie die Atome strukturiert und wurden in einer Liste der Gleitkommazahlen zusammengefaßt. Bei der Auswertung mu\ss te eine etwa auftretende Gleitkommazahl quotiert werden.

      LISP1.5 führt auch ganze Zahlen ein und ändert die Struktur beider Zahlentypen wesentlich. Es kann viele Zahlenobjekte gleichen Wertes geben. Zahlen können ohne Quotierung ausgewertet werden -- sie selbst sind das Ergebnis.

       

    2. LISP1.5 erlaubte die Punktnotation {\tt(A . B)}.

       

    3. LISP1.5 führt Felder ein.
    4. LISP1.5 ändert auch die Atomstruktur (es gibtnur noch APVAL als Indikator des globalen Wertes).
    5. LISP1.5 führt die Notation \$\$x ... x für Atome mit Sonderzeichenein.
    6. LISP1 erlaubte keine zyklischer Strukturen.
  2. {\bf Unterschiede bei den Funktionen}
    1. LISP1 erlaubte nur Funktionen mit 10 Argumente. LISP1.5 erweitertdies bis zur Zahl 20.
    2. In LISP1 durfte nur LIST unbestimmtviele Argumente haben. LISP1.5 systematisiert dies und führt eine ganze Reihe solcher Funktionen ein.
  3. {\bf Änderungen in dem Funktionsspektrum}
    1. LISP stellte für die Arithmetik nur die Funktionen {\tt SUM,PRDCT} und EXPT für Addition, Multiplikation undExponentiation zur Verfügung. LISP1.5 hat ein breites Spektrum (s. Abschnitt 5.3).
    2. LISP1.5 führt die Ein- und Ausgabefunktionen fürZeichenmanipulation ein.
    3. In LISP1 hatte man versucht, durchHilfsfunktionen die Verarbeitung von Funktionen der {\tt CAR-CDR}-Familie zu effektivieren (DESC, MAKCBLR, PICK).LISP1.5 beseitigt dies, indem es dem Nutzer überlassen wird, für die erforderlichen Funktionen zu sorgen.
    4. GO war in LISP1 eineSUBR und wertete das Argument in üblicher Weise aus.
    5. DurchEinführung der gepunkteten Paare wird die A-Liste anders strukturiert und mit ihr die Funktion SASSOC.
    6. Die Funktion TRACKLIST heißtjetzt TRACE.
    7. CSET und CSETQ werden in LISP1.5 eingeführt.
    8. Die Funktion ERRORSET wird für den Beweis-Überprüfervon Abrahams in LISP1.5 eingeführt.
  4. {\bf Änderungen am Compilersystem}
    1. Das LAP hat eine neue Struktur: Marken sind Atome in derProgrammebene, die Befehle haben so ein Element weniger.
    2. DerLISP1.5-Compiler ist wesentlich neu. Er erzeugt Funktionen, die fürtemporäre Variable Speicherplatz im Keller belegen.
  5. {\bf Änderungen im Verarbeitungssystem überhaupt}
    1. In LISP1 war eine Art APPLYQUOTE die Hauptfunktion: DerNutzer hatte Triplets zu liefern: Funktion, Argument und A-Liste. In LISP1.5 ist EVALQUOTE die Hauptfunktion. der Nutzermu\ssDoublets von Ausdrücken liefern: Funktion und Argumentliste.
    2. In LISP1 sprach man davon, da\ssAtome eine Assoziationsliste haben unddas System mit einer Eigentschaftsliste arbeite. In LISP1.5 sind die Bezeichnungsweisen vertauscht worden.
    3. Das Flexowritersystem wurde inLISP1.5 beseitigt.
    4. Die Objektliste ist als Hash-Liste organisiert.
    5. Die Fehlermeldungen sind weitgehend geändert.
    6. Jedes {\ttPROG} mußte in LISP1 mit einem RETURN beendet werden.
    7. Ein Spaßvogel sorgte dafür, da\ssam Anfang und Ende eines Laufsdes LISP1.5-Systems Begrüßung und Endzeitangabe in Form eines {\sc Lewis Caroll}-Zitats erfolgte.

Nicht unerwähnt bleiben darf die Tatsache, da\ssaus etwa 90Funktionen inzwischen rund 140 geworden waren. Da\sszusätzlich eineUnmenge von Details in der Implementation geändert worden waren, versteht sich von selbst.

Das LISP1.5 Manual [MCC62c] stellt heute die klassische Beschreibungder Sprache LISP dar. Es hat sich gegenüber seinem Vorgänger von 1960 durchgesetzt wegen der Veränderungen und Verbesserungen und wegen des fehlenden Nachfolgers. Die kurze Verwendungszeit des LISP1-Systems auf der IBM704 hat dieses System fast völlig in den Schatten treten lassen. So gibt es heute Stimmen, die LISP1 mit dem sogenannten ``reinen LISP''(LISP ohne Prog-Feature und Seiteneffekte) gleichsetzen. Da\ssdies nicht korrekt ist, zeigt ein kurzer Blick auf die von {\scMcCarthy} in [MCC60c] angegebenen Teile des Systems, die dasProg-Feature mit eingeschlossen. Wie McCarthy berichtet[MCC76], gab es ja von Anfang an sequentielle Elemente und Zuweisungen.

Der Terminus ``reines LISP'' wird erst im LISP1.5 Manual ([MCC62c],S.14) verwendet (``the pure theory of LISP''). Er bezeichnet hier den Komplex, der aus M-Sprache, S-Ausdrücken, Übersetzungsproze\ssM- zuS-Ausdrücken und theoretischen universellen Auswertungsprogramm APPLY/EVAL besteht. Jedoch ``...der Leser sei gewarnt, denn dieseFunktionen sind nur pädagogische Mittel...''.

Ein weiteres terminologisches Problem stellt die Bezeichnung LISP1.5 dar. Nach McCarthy ist dieser Name erst 1962 eingeführtworden, als die Variante für die IBM7090 bereits lief. ``Der Name kam mit dem neuen Manual'' [Mcc76]. Man fühlte offenbar, da\ssdas neueSystem dem alten wesentlich überlegen war. Man wollte aber nicht zu der Bezeichnung LISP2 greifen, weil die Ideen für LISP2 schon entwickelt worden waren [MCC76]: ``Wir wußten schon, da\sswir LISP2schreiben wollten.'' Die Ideen für LISP2 scheinen von Anfang an durch das Erscheinen von ALGOL in eine ganz bestimmte Richtung gegangen zu sein. Erste Veröffentlichungen zu LISP2 tragen diesen Namen jedoch nicht (vgl. allerdings [ED61]) und sind erst ab 1963 nachweisbar (z.B. [MCC63f.]).

Das LISP-System auf der IBM7090 gab den Benutzern große Arbeitsmöglichkeiten. Es war mit einem rudimentären Stapelverarbeitungssystem (OVERLORD) versehen, das dieAbarbeitung von geschlossenen Paketen von Funktionsaufrufen gestattete und die Rettung bzw. Wiederherstellung des Systems auf einem Magnetband überwachte.

Entscheidend geprägt wurde das System durch das Eingabeformat (Doubletten von Funktionsnamen und Argumenten) und durch den Interpreter, der auf A-Listen-Verarbeitung beruhte. Nur in Ansätzen implementiert war die Arbeit mit Eigenschaften und P-Listen, was durch die EXPR-Form (d. h. nicht als Maschinenprogramme) derwichtigsten P-Listen-Funktionen ({\tt DEFINE, DEFLIST, CSET, CSETQ, FLAG} usw.) belegt ist. Durch ATTRIB kam die neuesteEigenschaft ans Ende der P-Liste.

Die insgesamt implementierte Menge von Funktionen war mit 113 Elementen schon so enorm, da\ssdas Programmsystem insgesamt 170 000(oktal) Worte umfaßte. Der überarbeitete Compiler stellt den Ursprung einer ganzen Familie von Compilern dar, die teilweise noch heute im Gebrauch sind.

Noch bis in die siebziger Jahre bezog jede LISP-Implementation wesentliche Teile ihrer Entwurfsphilosophie aus dem LISP1.5-System auf der IBM7090 des MIT.

Diese kurze Charakteristik genügt an dieser Stelle. Im Kapital 5 wird die LISP1.5-Implementation näher beschreiben.

Das LISP1.5-System übte eine starke Anziehungskraft auf alle Wissenschaftler aus, die im Umkreis von Cambridge an Problemen der Sprachimplementierung und künstlichen Intelligenz arbeiteten. Die mit LISP geschriebenen Programme erschlossen einen ganz neuen Bereich der Programmierung und die Schöpfer dieser Programme wollten die so vorteilhafte LISP-Umgebung nicht mehr missen. Mußten sie ihren Arbeitsort wechseln so nahmen sie das System mit. Der Kreis um {\sc McCarthy} schwoll in kurzer Zeit stark an. Viele der heute auf dem Gebiet der künstlichen Intelligenz maßgebenden Wissenschaftler haben damals an der LISP1.5-Implementation mitgewirkt. Die eigentliche Hauptarbeit war natürlich von den beiden Programmierern geleistet worden.

Nach den Angaben des Manuals [MCC62c][S.iv] sind folgendeArbeitsgebiete bekannt: Interpreter -- S.B.Russell und D.J.Edwards; Ein- und Ausgabe -- J.McCarthy, K.Maling, D.J.Edwards und P.W.Abrahams; Garbage Collection und Arithmetik-- D.J.Edwards; Compiler -- T.P.Hart und M.I.Levin.In der anregenden Umgebung sind zu nennen: {\sc M.L.Minsky, B.Raphael, L.Hodes, D.M.R.Park, D.C.Luckham, D.G.Bobrow, J.R.Slagle, N.Rochester, C.E.Shannon, R.K.Brayton, L.Kleinrock, S.H.Goldberg, P.Fox, H.Rogers} Jr., H.Teager, D.A.Dawson, E.L.Ivie, P.G.Jessen und U.Schimony.

Als McCarthy im November 1962 das MIT verließ, um einemRuf nach Stanford zu folgen, begann LISP bekanntzuwerden. Implementationen auf anderen Rechnern wurden gemacht, größtenteils von Teilnehmern an Sharing-Systeme und den dadurch möglichen interaktiven Betrieb sollten sich die Eigenschaften von LISP weiterhin bewähren.

Der Anfang war gemacht.

 

 

Lokale Verbreitung von LISP 1962--1966

Mit dem Wechsel von McCarthy vom MIT Cambridge zur StanfordUniversity war ein zweites LISP-Zentrum entstanden.

Zunächst arbeitete McCarthy (mit den ihm folgenden Helfern)in der ``Computer Science Division'' des Departement für Mathematik, später (1964) spaltete sich die Abteilung als eigenständiges Department ab. Die erste Zeit war neben der Verfolgung theoretischer Arbeiten [MCC63c,d] der Übernahme des LISP-Systems und seinerVerbesserung gewidmet. Als das Stanford Artifical Intelligence Project im Juni 1963 eröffnet wurde, hatte McCarthy sechs Mitarbeiter[EAR73].

Die nächste Etappe der Weiterentwicklung von LISP ist wesentlich durch die Arbeiten auf dem Gebiete der Time-Sharing-Systeme gekennzeichnet.

Die Idee, einen Rechner dadurch mehreren Benutzern verfügbar zu machen, da\ssman die Arbeitszeit der Zentraleinheit stückelt und dieZeitquanten gleichmäßig verteilt, taucht etwa 1958 bis 1959 auf [STR59].

McCarthy hatte schon 1959 begonnen, verwandte Ideen in die Tatumzusetzen. noch auf der IBM704 war ein System aufgebaut worden, das auf dem Einschieben kleiner Programmstücke zwischen die Jobs eines Stapelverarbeitungssystems beruhte. Das Betriebssystem fragte nach Beendigung eines Jobs, ob von einem Terminal (damals zumeist ein einfacher Fernschreiber oder Flexowriter) eine Eingabe zu machen wäre und bediente, falls die Frage positiv beantwortet wurde, damit ein Zwischenprogramm. Wenn die Jobs im Stapel auf eine Verarbeitungszeit von 1 Minute begrenzt waren, so konnte der arbeitende Programmierer mit einer akzeptablen Antwortzeit rechnen. Allerdings mußte das Programm für die Dialogarbeit ständig im Hauptspeicher sein. Durch einen Gl\" ucksumstand waren dafür die Voraussetzungen gegeben: Die Kundenprogramme erwarteten nur einen verfügbaren Speicherplatz von 8192 Worten, während der Speicher gerade auf 32768 Worte vergrö\ss ert worden war [MCC78a]. Nachdem Edwards und Luckham[MCC60a] Anfang 1960 die nötigen Routinen geschrieben hatten, konnteMcCarthy die Vorteile der On-Line-Arbeit studieren. Offenbar warder an sich bescheidene Erfolg so ermutigend, da\ssMcCarthy sichstark für das Time-Sharing einsetzte. Das LISP1-System diente zur Demonstration der Vorteile interaktiver Arbeit, obwohl es eigentlich keine Zeitaufteilung benutzte, sondern sonst verlorene Zeit ``stahl''. Deshalb wurde dieses rudimentäre Verfahren auch Time-Stealinggenannt [ MCC78a].

Durch McCarthys Initiative wurde am MIT Interesse wach, und eswurden Studiengruppen gegründet, die sich mit dieser Problematik befassen sollten. McCarthy leitete das MIT Computer WorkingCommittee und war Mitglied in einem Preliminary Study Commitee. Man bot ihm sogar die Leitung des MIT-Rechenzemtrums an, um die Implementierung eines Time-Sharing-Systems direkt leiten zu können, doch er blieb bei der Künstlichen Intelligenz. So wurde H.Teager, der Leiter der zweiten Studiengruppe, Organisator der MIT Arbeit zum Time-Sharing\footnote{In seiner ausführlichen Darstellung der frühen Geschichte der Time-Sharing-Systeme hebt {\sc T.J.Glauthier} [GL67] den Anteil von MCCarthy hervor. {\scGlauthier} zeigt die Beziehungen des CTSS zu den frühen interaktiven Systemen (z.B. Fitzgeralds Remote Computing System von 1955)und dem militärischen Großprojekt SAGE, einer Gemeinschaftsarbeit von Militärs, MIT und Lincoln Laboratories, an dem unter anderen die Time-Sharing-Pionere Forrester, Fano, Licklider, Miller, Minskyund Mccarthy mitgewirkt hatten. Daneben erwähnt er dieGründung der Firma Digital Equipment durch IBM-Mitarbeiter (als diese durch ihre Erfahrung, gewonnen bei der Arbeit an SAGE, zur Entwicklung eines neuen Rechners geführt wurden, trennten sie sich von IBM, sei es, weil man sie nicht genug förderte sei es, weil ihnen die kommerzielle Bedeutung ihrer Idee klar war) und die Entwicklung des pdp-1, der von seiner Struktur her für Time-Sharing geeignet war.

Nach Glauthier besteht folgende zeitliche Abfolge: 1. CTSS aufIBM7090 (Corbato, MIT) 1961; 2. BBN auf pdp-1 (McCarthy,BBN) Sept. 1962; 3. JOSS (RAND-Corp) Mai 1963; 4. auf pdp-1 ({\sc Fano}, MIT) Mai 1963); 5. auf pdp-4 (Adams , Adams Ass.Inc) Juli 1963; 6. auf Q-32 (Linde, SDC) Juli 1963; 7. auf pdp-1(McCarthy, Stanford) August 1963; wenig später das Basic-Systemam Darthmouth-College.}.

Allerdings scheinen seine Ideen etwas unrealistisch zu sein; jedenfalls zog F.J.Corbato einen bescheidenen Entwurf vor undbegann 1960 auf eigene Faust, sein experimentelles Time-Sharing-System zu realisieren. 1961 lief auf einer IBM7090 die erste experimentelle Version [COR62a] dieses Systems. Man sammelte rasch Erfahrungen, undauch das LISP-System, ohne wesentliche Änderungen, lief unter der Steuerung dieses Betriebssystems. Im Verlauf des Jahres 1962 wurde so aus einem Versuch das bekannte CTSS [COR62b], das schließlich aufder IBM7094 lief.

McCarthy hielt nicht nur popularisierende Vorlesungen überTime-Sharing-Systems für die pdp-1 bei der Firma BBN [MCC63b].

Die Programmierarbeit leistete unter der Anleitung von E. Fredkin einAngestellter der Firma, Boilen. Da der Rechner sehr klein war, nur 8 Kumfaßte, konnte man nie mehr als ein Programm unterbringen. Fredkinerdachte als ``schlechte Ersatzlösung'' die Auslagerung des gesamten Programms auf die Trommel und die Einlagerung des neuen Programms. Glücklicherweise konnte beides mit einer Operation ausgeführt werden. Die so entdeckte Technik des Swapping ist dann in fast allen Time-Sharing-Systemen dieStandardlösung geworden. Obwohl bei der Trennung McCarthys vom MITausgemacht worden war, da\ssdie Weiterentwicklung und Pflege des LISP-Systemsnun in Stanford stattfinden sollte [MIN63a], erzwangen die durch denTime-Sharing-Betrieb erforderlichen Umstellungen viele Arbeiten am MIT. Die tägliche praktische On-Line-Arbeit mit LISP im CTSS erwies die vortreffliche Eignung der Sprache und des Programmiersystems für die Dialogarbeit; sind doch Programme, Eingabe- und Ausgabedaten in einundderselben Sprache.

Die Entdeckung von Fehlern und die Verfolgung von Wünschen, die bei der Verwendung des Systems entstanden, führte zur ständigen Pflege und Überarbeitung auch am MIT. Des öfteren wurden verbesserte Versionen in den Dienst gestellt [ED64a, MART64]. Unter der Erweiterungen mu\ssdie Einführungvon Makros erwähnt werden, die durch Hart [HART63b] ausgelöstwurde. Bemerkenswert an der Implementierung des Makro-Konzepts war, da\ssdieLISP-Makros während der Interpretation wie spezielle Funktionen behandelt wurden, indem nämlich die Expansion eines Makros durch Berechnung des auszuwertenden Ausdrucks vorgenommen wurde. Die Makro-Expansion während der Compilierung unterschied sich nicht von der in anderen Programmiersprachen üblichen Verfahrensweise.

Eine zweite wesentliche Arbeit, die an LISP geleistet wurde, war die Bemühung, sekundäre Speichermedien in die Arbeit auszuschließen. Einen guten Überblick über den Stand vermittelt die Arbeit von Edwards [ED63]``Sekundäre Speicher in LISP''. Der Autor berichtet über die Magnetbandarbeit im ursprünglichen 7090-LISP und die erweiterte Benutzung dieser Geräte durch LISP-Bibliotheken, in denen Funktionen sowohl im Quellformat, d. h. als S-Ausdrücke, als auch im LAP-Format, d. h. als compilierte Funktionen, stehen könnten.

Für die Anordnung compilierter Funktionen im Hauptspeicher schlägt Edwards der Ring-Puffer vor, der es ermöglicht, da\ssjede geladeneFunktion eine bestimmte Zeit im Speicher verbleibt. Da aktive Funktionen vor dem Entferntwerden geschützt werden sollten, versprach sich Edwards von dieser Lösung, da\sssie in typischenLISP-Situationen nahezu in voller Maschinengeschwindigkeit angesprungen und abgearbeitet werden könnten.

Durch die Kombination dieser Idee mit der von Minsky geäußertenVorstellung über ein kompaktierendes Garbage Collection, das die sekundären Speichermedien nutzt [MIN63c], könnte man dieGrößenverhältnisse von Ring-Puffer und Listenspeicher entsprechend den dynamischen Anforderungen ändern.

Eine dritte Möglichkeit, die Edwards sah, um mit zu umfangreichenFunktionsmengen auszukommen, besteht in der Deklaration von ``demnächst'' benutzen Funktionen, die dann vorsorglich zu laden wären.

Für die LISP-Geschichte von höchstem Interesse sind Edwards'Ausführungen zu Paging-Techniken. Nach seinen Angaben hatte man schon 1963 einen pdp-1 am MIT mit einem virtuellen Speicher versehen (McCarthy undFredkin halten J.Dennis für den Projektverantwortlichen[FRE77]). Der pdp-1, der 4096 Worte \'a 18 Bit besaß, stellte normalerweisenur etwa 800 Worte für den Listenspeicher bereit. Durch Seitenaustausch mit einer Trommel, die 88K Worte aufnehmen konnte, wurde dieser Arbeitsspeicher wesentlich vergrößert. Edwards bemängelt die noch unvollkommenenTechniken des Software-Paging für die Bezugnahmen auf andere Seiten (cross page references) und die daraus resultierende enorme Verlangsamung des Rechenprozesses. Leider erwähnt er nicht die Entwickler des Systems und gibt auch sonst keine Daten.

Die heute oft verwendete Methoden des Auslagerns von Zwischenergebnissen mittels symbolischer Ausgabe auf arbeitsdateien, von denen sie, falls benötigt, wieder eingelesen werden können, werden von Edwards skeptisch beurteilt.Die Ursachen hierfür liegen in den zu hohen Anforderungen, die der Autor an diese Variante der Verwendung von sekundären Speichern stellt. aus heutiger Sicht erscheint die Begrenzung dieser Methode auf normale Listenstrukturen als völlig ausreichend. Die zyklischen und BLAM-Listen ([ED63], S.5), mit denensich Edwards beschäftigt, treten doch verhältnismäßig selten auf.

Als letzte Möglichkeit für die Arbeit mit externen speichermedien beschreibt Edwards noch den automatischen kompaktierendenListenstruktur-Hauptspeicherauszug, durch den versucht werden soll, wenigstens einen teil des aktiven Listenspeichers zeitweise auf sekundäre Speicher abzulagern.

Alles in allem bietet diese Arbeit eine gute Übersicht über das LISP-Know-How jener Zeit. Sie war für den 1. Internationalen LISP-Kongre\ssvorgesehen, dervom 30.12.1963 bis zum 3.1.1964 in Mexiko City stattfand. Diese Konferenz sollte als erstes internationales Forum für die Diskusion der Sprache und ihrer Implementierung dienen. Allerdings sind von den Materialien dieser Konferenz nur die beiden Arbeiten von Minsky und Edwards bekannt.

Da\ssein solches Treffen sinnvoll war, zeigt die um die Jahreswende 1963 bis1964 gestiegene Aktivität bezüglich LISP. In Cambridge wurde an mehreren Stellen an der LISP-Implementation gearbeitet; in Stanford wurde das alte System überarbeitet, und weitere Zentren, an denen LISP bearbeitet wurde, waren im Entstehen. Einen recht guten, allerdings unvollständigen Überblick über die Lage Ende 1963 gibt der Artikel von Borrow und Raphaelüber Sprachen für die Symbolmanipulation [BO64c].

\begin{center} \underline{CENTRO DE CALCULO ELECTRONICO.} \underline{CIUDAD DE MEXICO} Mexico, 20, D. F. \underline{FIRST INTERNATIONAL LISP CONFERENCE} december 30, 1963 - January 4, 1964 \underline{Preliminary List of Participants and papers}

\end{center}

 

 
DULOCK, VICTOR.- LISP. Applications to Symmetric group, Dirac groups and
Lie algebras.
EDWARDS, DANIEL.- Secondary Storage in LISP.
EVANS, THOMAS.- Character String manipulation in LISP.
HART, TIMOTHY.- Macro Instructions for LISP.
HAWKINSON, LOWELL.- Data structures and arrangements in LISP.
HEARN, ANTHONY C.- LISP. Computation of Feynman Graphs.
LEVIN, MICHEL.- Algebraic Compiler with LISP.
Mc. CARTHY, JOHN .- The LISP. 2 Compiler
Mc. INTOSH, HAROLD V.- The use of operator predicates in LISP.
MINSKY, MARVIN.- Garbage Collector methods
THOMAS, BILLY S.- Use of arrays in lisP. Group theory Programms.
WEIZENBAUM, JOSEPH.- Open Ended compilation.
WILLIAMS, JOSEPH.- A LISP. Page plotter.
WOOLDRIDGE, DEAN.- An Algebraic Simplify Program in LISP.
YATES, ROBERT.- LISP. Group Analysis programs in LISP.
  Compiler for a variable word machine (Gamma 30
Scientific)
RUSSELL Debugging aids
VERHOVSKY Fns analoguous and similar
  December 15. 1963

\begin {center} Abb. 8. Programm der 1. Internationalen LISP-Konferenz \end{center}

Diese Arbeit enthält keinen Hinweis auf die Bemühungen von H.McIntosh um die Weiterverbreitung vonLISP. Dieser hatte etwa 1960 am MIT diese Programmiersprache kennengelernt und zunächst an der University of Florida eine LISP-Version implementiert, mit der er experimentierte. Später, Anfang 1963, ging er als Professor an die Universität von Mexiko nach Mexiko City. Dort scharte er einen Kreis von Studenten um sich, mit denen er Probleme der symbolischen Informationsverarbeitung in Angriff nahm. Man verfügte Ende 1963 über eine IBM709 und benutzte entweder die originale LISP 1.5-Version aus Cambridge oder eine eigene Variante. Mitarbeiter McIntoshs waren damals unteranderen A.Guzman und L.Hawkinson.

Der letztere war zu dieser Zeit schon kein LISP-Neuling mehr. Er hatte LISP etwa 1962 kennengelernt und an der Yale-University ein System aus Interpreter und Compiler für eine IBM709 programmiert. Er folgte McIntosh über dieUniversity of Florida nach Mexiko, wo er erneut an einer Implementation arbeitete. Am Ort der Konferenz herrschte demnach ein anregendes Klima für die Weiterentwicklung von LISP.

Über vier der Systeme, die damals in Cambridge aufgebaut wurden, liegen gute Informationen vor. Alle vier haben einigen Einflu\ssauf die Weiterentwicklungder Implementierungstechnik und der äußeren Form der Sprache LISP gehabt.

Das von Hart und T.G.Evans für einen M460 [TH58] in den Air ForceCambridge Research Laboratories entwickelte LISP-System [HART64a] zeigtesich durch seine damals neuartige Entwicklungstechnologie aus: Zunächst wurden die Hauptfestlegungen über die internen Strukturen getroffen und der Garbage Collector programmiert. Dann wurden alle erforderlichen Maschinenroutinen geschrieben ({\tt CAR, CDR, CONS, RPLACA, ATOM, GENSYM, NUMBERP, PLUS, TIMES, GREATERP, EQP, READ, PRIN1, TERPRI, PUN1, TERPUN, EVALQUOTE, SET, VALUE} und einige andere). Die Hauptarbeit bestand in der Herstellung eines LISP-Compilers in LISP (durch Modifikation des 7090-LISP-Compilers) und dessen Verwendung, um den LISP-Interpreter und die restlichen Grundfunktionen für die neue Maschine zu übersetzen. Diese Arbeit wurde auf der IBM7090 durchgeführt. Resultat war ein großes Maschinenprogramm, das zu den vorher geschriebenen einzelnen Routinen hinzugefügt wurde. Schließlich wurde auch der zum Transport verwendete Compiler in die neue Umgebung übernommen.

Aber nicht nur technologisch stellte das M469-LISP eine Neuheit dar. Es enthielt drei wesentliche Unterschiede zum LISP1.5 auf der IBM7090, denen zukunftsweisende Ideen zugrunde lagen: Die Interpretation basierte auf dem A-Listen-freien Zugriffsschema (shallow access) (vgl. S.208) und arbeitete nur mit Kellerspeicher und Wertzellen.

Um die Speicherstruktur zu vereinfachen und einfache Zeichenkettenverarbeitung durchzuführen, hatte man Namen und Zahlen als Listen von Zahlen bzw. Zahlstücken implementiert (character string lists). Abgesehen von den compilierten Programme mußte der Speicher daher nicht in getrennte Bereiche aufgeteilt werden.

Die Zeichenlisten erforderten ein neues Syntaxelement: Um S-Ausdrücke einlesen zu können, die solche Zeichenliterale enthielten, kam man zur übereinkunft, jedes Zeichenliteral mit einem Schrägstrich anzukündigen, etwa {\tt(/A/B/C)}. \begin{picture}(400,80) \put(20,0){\framebox(40,20)}\put(50,0){\framebox(40,20)}\put(100,0){\framebox(40,20)} \put(20,0){00013}\put(50,0){00014}\put(100,0){00015} \end{picture} \begin{center} Abb.9. Die Zeichenkettenliste {\tt(/a/b/c)} im M460-LISP ([HART64a], S.197)\end{center}

Eine weitere Differenz, die aber für den Nutzer des Systems nicht sichtbar wurde, bestand in dem kompaktierenden Garbage Collector. Soweit bekannt, ist dieses Schema hier zum erstenmal benutzt worden.

In der ersten Phase wurden die aktive Zellen markiert. Da die Zeiger das ganze Wort belegten, mußte mit Bittafeln gearbeitet werden, um die Benutzung einer Zelle anzuzeigen. Die Ausgangsbereiche für das Markieren waren compilierte Programme und Kellerspeicher (Objektliste wird nicht erwähnt). Während der Markierung wurden die aktiven Zellen gezählt.

Anschließend wurde in der 2. Phase der Speicher aufgeteilt in den zu verschiebenden Bereich und in den festen Bereich; im festen Bereich wurden die freien Zellen erfaßt.

Die Zellen des zu verschiebenden Bereiches wurden in der 3. Phase in diesen freien Zellen verschoben. Dabei kam ein Zeiger auf den neuen Platz in die alte Zelle.

Zum Schlu\ssmußte in der letzten Phase der gesamte Speicher nach Bezugnahmenauf verschobene Zellen im zu verschiebenden Bereich durchsucht und die neue Adresse eingesetzt werden.

Kurz nach Fertigstellung des M460 LISP begann Saunders für denQ-32-Computer\footnote{genaue Bezeichnung AN/FSQ-32/V, nach McCarthy[MCC76] ein militärischer Rechner; nur der eine ... wurde fürwissentschaftliche Arbeit benutzt. Die Maschine hatte einen 64K Speicher von 48 Bit Worten und war im Prinzip eine bessere Maschine als die 7090. Allerdings bekam sie nie mehr Speicher und war schwer zu warten. Nach Glauthier [GL67] war die Q-32 eine von der 7090 abgeleitete IBM-Maschine.

Wichtig für LIsp war, da\ssdieser Rechner im Time-Sharing-Betrieb lief undauch hardwaremäßig an die damit zusammenhängenden Aufgaben angepaßt war. Allerdings soll das Software-Paging recht langsam gewesen sein.} der Firma System Development Corporation, Santa Monica,ein LISP-System aufzubauen, das sich stark auf die Erfahrungen und Ergebnisse, die bei der Arbeit mit dem M460 gemacht worden waren, stützte.Saunders erwähnt die konkrete Hilfesowohl von Hart, Edwards und Levin von Combridge von Russell undMcCarthy aus Stanford.

Das Q-32-LISP [SAU64b] hielt sich im wesentlichen an dieLISP1.5-Festlegungen. Das von Hart entwickelte Makro System war Bestandteildes Interpreters. Neu war die Eigenschaft des Q-32-LISP, da\ssalle Funktionen,die mit DEFINE bzw. da\ssalle Makros, die mit MACRO definiertwurden, sofort compiliert wurden. Der Compiler benutzte daher nicht mehr die Common-Variablen, die im 7090-LISP1.5 notwendig waren, um die Arbeitvon Interpreter und compilierten Programmen zu koordinieren, sondern nur noch SPECIAL-Variablen. Diese ersetzten auch die APVAL-Größen.

Das Garbage Collection basierte, wie schon im M460-LISP, auf einem Kompaktierschema.

Die Technologie für die Herstellung des Q-32-LISP ist derjenigen, die beim M460-LISP angewandt wurde, sehr ähnlich. Nach Saunders [Sau64b] wurde halbin der Assemblersprache SCAMP und halb in LISP programmiert. Der LISP-Teil, der etwa 1900 Karten ausmachte, wurde auf der IBM7090 compiliert -- ein Vorgang, der 40 Minuten in Anspruch nahm.

Der Teil, der in der Assemblersprache notiert war, enthielt die Grundfunktionen, einen Programmteil, der das auf der IBM7090 produzierte Resultat (auf Magnetband) der Compilierung einlas und verarbeitete und schließlich einen Teil, der Hauptspeicherabzüge im Q-32-System ausführen konnte.

Compiler, (LAP)-Assembler und eine Unmenge von LISP-Funktionen waren in demLISP-Teil enthalten. Dieser Teil der Programme des Q-32-LISP ist vollständig beschrieben in [SAU64c].

Überhaupt galt das Q-32-LISP (vgl. auch [KAM64, WEIS65]) als hervorragendbeschrieben [AB68], und der veröffentlichte Compiler dürfte bei vielen späterentwickelten LISP-Systemen Pate gestanden haben.

Q-32-LISP hat sich noch etwas weiterentwickelt (schon Saunders berichteteüber zwei Versionen, Mark I und II) und wurde bis Ende 1967 benutzt. Es hatte zeitweise große Bedeutung als Basissystem für CONVERT [GUZ66] und LISP2[AB66b], da der Q-32 über Fernverarbeitung sogar aus Mexiko-City erreichbar war.

Aus einem ähnlichen Grund, wie er bezüglich des Q-32-LISP gegeben ist wurde das pdp-1-Basic-LISP [DEU64] bekannt: Bei seiner Beschreibung wurden nicht nur allgemeine Eigenschaften angegeben, sondern der gesamte Interpreter ist als Assemblerprogramm veröffentlicht worden.

Dieses System ist von L.P.Deutsch erstellt worden, der 1963 am MITstudierte, allerdings mehr privaten Programmierinteressen als dem Studium nachging. Die erste Version lag im Oktober 1963 vor, eine weitere Verbesserung wurde im März 1964 fertiggestellt. Möglicherweise war dieses System auch die Basis des pdp-1-LISP von Edwards [ED63] in dem virtuellenSpeicher.

pdp-1-Basic-LISP benutzte minimal 2000 Worte und konnte in einem erweiterten 16k-pdp-1 den gesamten Speicher belegen. Natürlich konnte in einer so begrenzten Umgebung nicht viel gemacht werden. Die Eingabemedien waren Fernschreiber und Lochstreifenleser; die Ausgabe erfolgte normalerweise auf dem Fernschreiber. Bei der Eingabe hatte der Nutzer genauer als im LISP1.5 auf das Format (bestimmte Forderungen an Leerzeichen) zu achten, da das Einleseprogramm nicht so variabel war.

Deutsch's System war das erste, das sich konsequent von der übergeordnetenFunktionen EVALQUOTE löste und EVAL an ihre Stelle rückte. Daraus folgtedie etwas unbequeme Notwendigkeit, die Argumente im Hauptniveau (top level) zu quotieren. Eine weitere Erfindung von Deutsch ist das Slash-Zeichen. Impdp-1-LISP konnte nach dem ``--'' (overbar) jedes beliebige Zeichen auftreten und wurde als Buchstabe behandelt.

Dieses LISP-System sollte nicht das letzte auf einer pdp-1 sein, denn diese Maschine zeichnete sich durch eine große Flexibilität und eine für jene Zeit ungewöhnliche breite Peripherie aus.

Die Beziehungen, die die Herstellerfirma Digital Equipment zum MIT geknüpft hatte (auf Grund der örtlichen Nähe), waren immer sehr eng. In mehreren Fällen wurden neue Rechner sehr früh an das MIT geliefert. Ein wichtiges Beispiel für diese enge Zusammenarbeit war die Entwicklung eines LISP-Systems für die pdp-6.

Im Frühjahr 1964 begann eine Gruppe (zu der Greenblatt und Nelson gehörten)von DEC-Mitarbeitern und Mitgliedern des Technical Railroad Club, einer Interessengemeinschaft von Studenten am MIT\footnote{Mitglieder waren beispielsweise Russell, Saunders und A.Kotok, der das ersteSchachprogramm in LISP geschrieben haben soll}, einen Interpreter und ein minimales LISP-System für die pdp-6 zu entwerfen, zu programmieren und einzufahren [WHI70]. Dieser unwahrscheinliche Schritt (es gab zu dieser Zeitnoch keine arbeitsfähige pdp-6!) war möglich durch die Verwendung einer pdp-4, die gut ausgerüstet war und die die Arbeit der Programmverwaltung und -änderung, der Assemblierung und später die Ausgabe übernahm. Ob das Pogramm auch auf der pdp-4 gelaufen bzw. simuliert worden war, ist nicht bekannt. Man bedenke dabei, da\ssbeide Maschinen sich nicht sehr ähnlich sind, denn siegehören zwei getrennten Zweigen der DEC-Rechnerfamilie an (pdp-1, -4, -7 usw.; pdp-5, -8, -12 usw.; pdp-6, -10).

Als Mitte 1964 der erste pdp-6 Rechner [BEL78] an das MIT geliefert wurde,war das neue System das erste Programm, das auf der Anlage lief, und es diente gleichzeitig als Mittel, um die Maschine zu testen. Nach J.L.White [WHI70][S.v] war es das erste Programm, das überhaupt jemals aufeiner pdp-6 gelaufen ist.

Über die ursprüngliche Version ist nicht viel bekannt. Die ideen für den Entwurf sollen von der CTSS-Version auf der IBM7094 und den pdp-1-Basic-LISP genommen worden sein. Für länger Zeit mu\ssaber das pdp-6-LISP vollständig mitLISP1.5 verträglich gewesen sein. Es wurde zunächst mehr erweitert als geändert; insbesondere die Ein- und Ausgabemöglichkeiten verbesserten sich enorm (vgl. [MART65a, b]).

Die Mitglieder des Laboratoriums für künstliche Intelligenz am MIT machten auch die neue DEC-Anlage populär [ED64b].

Auch die LISP-Systeme auf den IBM7090- bzw. 7094-Maschinen befanden sich in ständiger Weiterentwicklung. Dies war hauptsächlich erforderlich, weil ursprünglich LISP in einer Umgebung gearbeitet hatte, die nicht durch ein Betriebsystem organisiert worden war. Durch den Aufbau von speziellen und ganzen Betriebssystemen (z.B. FORTRAN MONITOR SYSTEM des CTSS) ergab sich die Notwendigkeit, LISP an diese Basissysteme anzupassen. Nachdem dies geschehen war, wirkten sich vor allem die Erfahrungen aus, die beim interaktiven Umgang mit dem CTSS-LISP-System gewonnen worden waren. Die Arbeit bis Ende 1964 läßt sich in [PROM2] beurteilen.

An der Erweiterung dieses LISP-Systems arbeiteten nicht nur Hart undEdwards, sondern später neben L.Norton, W.Teitelman und W.Martin vorallen J.Moses und R.Fenichel. Diese beiden vollendeten Anfang 1966eine neue Version [MOS66].

Das geänderte System bot mehr Platz für die Daten und für verschiedene neue Funktionen. Die Ein- und Ausgabemöglichkeiten, die Fehlermeldungen (die bis dahin aus den alten Kürzeln des LISP1.5 von 1962 bestanden hatten -- vgl. [MCC62c][S.32]) und verschiedene Unterprogramme wurden verbessert. Dabeiwurden viele alte Fehler entfernt. Einige Fehler mußten als zwar bekannt, aber noch nicht beseitigt, angezeigt werden [MOS66][S.7].

Die neuen Funktionen waren hauptsächlich numerischer Natur ({\em $ e^{x}$}, ln x, NUMVAL, EXPT), ermöglichten bessere Arbeit mit Teilen desLISP-Systems (so konnte der Nutzer z.B. die Zahl der freien Zellen im Bereich der compilerten Funktionen ermitteln, den Zeitgeber stellen bzw. abfragen usw.) oder erlaubten neue Aktionen mit Listen. Erwähnenswert ist hier die Funktion EXPLODE, die, ausgehend von einem beliebigen S-Ausdruck, eineListe von Zeichen liefert, wie sie beim Drucken des Ausdrucks auf dem Papier erscheinen (als Erfinder gilt W.Martin).

Dieses neue CTSS-LISP scheint nur am MIT genutzt worden zu sein. Es war offenbar auch das letzte Glied der Familie von LISP-Systemen, die am MIT für Rechner der Familie IBM704-IBM7094 aufgebaut worden waren. Mit dem Erscheinen der pdp-6 wandte sich das Interesse diesem Rechner zu, der teilweise unter der Aspekt der Anwendungen für die Listenverarbeitung entworfen worden war.

Verbreitet wurde dafür das Ergebnis der Arbeiten an der Stanford University. Zu den Arbeitsgebieten, die McCarthy ins Leben gerufen hatte, gehörte nebenFormelmanipulation [EN63b, RUS63b], neben der Entwicklung despdp-1-Time-Sharing-Systems auch die Weiterentwicklung des LISP1.5-Systems, das nach Stanford transferiert worden war.

Neben kleinen Additionen (Zeitfunktionen [EN63a]) und kleinen Änderungen (etwa amCompiler [WOL64a]), machte man sich Gedanken über die Verstärkung derFehlersuchhilfen im LISP-System [RUS63a]. Völlig neu waren einige Funktionen,die für die Arbeit mit Dateien auf Plattenspeichern gedacht waren. Sie ermöglichten das zeitweilige Ausgeben von S-Ausdrücken. Der Nutzer mußte allerdings seine Dateien selbst verwalten, um in den sequentiell aufgebauten Folgen von S-Ausdrücken den richtigen zu finden, den er einlesen wollte [WOL64b].

Dieses System, zeitweise LISP1.55 genannt, wurde der IBM-Nutzergemeinschaft SHARE übergeben. Mit einigen weiteren kleinen Zusätzen ist es in der Auflage 1965 des Manuals [MCC62c] als Anhang I beschrienben. Seine Fertigstellung istdort auf den Februar 1965 datiert.

McCarthy und seine Mitarbeiter hatten Einflu\ssauf die Implementierung desQ-32-LISP. Fallweise dürfte dieses System auch von Stanford aus benutzt worden sein. Gemeinsam mit dem MIT arbeitete man am Entwurf von LISP2, wofür öfters Konferenzen abgehalten wurden und Positionspapiere erarbeitet wurden [MIT64]. Eine für die LISP-Geschichte folgenreiche Entwicklung begann ca.1963 mit A.C.Hearns Arbeit an seinem LISP-Programm für die Berechnung vonWirkungsquerschnitten von Elementarteilchenreaktionen mittels Feyman-Diagrammen. Hearn, zu dieser Zeit als Physiker arbeitend, fandviel Gefallen an der Symbolmanipulation und begann 1965 mit dem Aufbau eines der wichtigsten (und sicher meistbenutzten) Formelmanipulationssysteme.

Für manche der bearbeiteten Aufgaben und die meisten Projekte war jedoch das LISP-System auf der IBM7090 nicht leistungsfähig genug und die Anlage selbst zu klein. Die Situation sollte 1966 durch eine pdp-6 grundlegend verändert werden (vgl. [MCC65]). Zwischen 1963 und 1964 wurde von Studenten in Stanfordein kleines LISP-System für die B5000 erstellt. Es mußte in ALGOL, der Maschinensprache dieses Rechners, programmiert werden.

Mit dem Ausscheiden von Bobrow aus dem MIT und dem Beginn seiner Arbeit beider Datenverarbeitungsfirma BBN (Bolt, Beranek \& Newman) war das dritte LISP-Zentrum in den USA entstanden. Bobrows Hauptarbeitsgebiet hatte am MIThauptsächlich bei der Symbolmanipulation [BO63a] und der Verarbeitungnatürlicher Sprache [BO64a] gelegen. Doch neben diesen bis heuteweitergeführten Interessengebieten hat er sich schon immer mit für diese Arbeitsgebiete erforderlichen Hilfsmitteln beschäftigt (vgl. z.B. \cite{BO64c, d}).

Er hatte schon frühzeitig die Auffassung entwickelt, da\ssSymbolmanipulation durch Hilfsmitteldes Mustervergleichs unterstützt werden muß, hatte diese Mittel aber in LISP vermißt (fand sie aber in COMIT [YN61, 62]). So setzte er sich denn auchdafür ein, die ``neue'' LISP-Version (d.h. LISP2) mit diesen Mitteln auszurüsten [BO64b, 65] und hatte überhaupt großen Anteil am Entwurf undmöglicherweise auch an der Implementation von LISP2 (wenigstens in der Anfangszeit).

BBN hatte 1964 eine Abteilung, die sich eingehend mit LISP beschäftigte. Dort wurde unter anderem Anfang jenes Jahres ein großes Experiment zum Vergleich von Programmiersprachen gestartet [BE64]: Zwölf ausgesuchte Programmiererhatten in den Sprachen, in denen sie als Experten galten, sieben verschiedene Probleme zu programmieren. Erfaßt wurden Parameter über die Zeit für den Programmentwurf, für die Testung usw. Dabei schnitt LISP erstaunlich gut ab.

So benötigten die ALGOL-Experten 2 Stunden, der FORTRAN-Experte 1 Stunde, der COBOL-Experte 2 Stunden und die LISP-Experte (Hart vom MIT) 1 Stundefür die Programmierung. Um das Programm auszutesten, brauchte der ALGOL-Bearbeiter 4 Stunden, der FORTRAN-Bearbeiter 15 Stunden (und das im Dialogbetrieb im CTSS!), der COBOL-Bearbeiter 6 Stunde und Hart mit demMIT-LISP-System 1 Stunde.

Der Betrieb des LISP-Systems unter CTSS sorgte dafür, da\ssHart in derGesamtbearbeitungsdauer deutlich vorne lag: Während für die Bearbeitung mit ALGOL 7 Tage, für die mit FORTRAN 16 Stunden (CTSS)! und für die mit COBOL gar 5 Wochen benötigt wurde, konnte Hart bereits 4 Stunden nach Empfang derAufgaben die vollständigen Lösungen abliefern.

Damit war bewiesen, da\ssLISP nicht nur zum Entwerfen und Austesten vonProgrammen geeignet, sondern auch leicht zugreifbar war.

Eines der ersten Projekte, mit dem Bobrow sich bei BBN beschäftigte, wardie Entwicklung eines neuen LISP-Systems für eine dort installierte pdp-1. Wie schon erwähnt, war dieser Rechner zwar klein (16K Worte zu 18 Bits) und einigermaßen schnell (Zugriffszeit 5$\mu$ s), aber er war einer der ersten echten Computer für Echtzeitaufgaben. Der pdp-1 bei BBN war mit einer ausgezeichneten Peripherie ausgestattet (Lochstreifenleser und -stanzer, Teletype mit Leser und Stanzer, Magnetbandgeräte mit Lichtgriffel und ein Graphic Tablet; dazu eine 88K Trommel mit einer Zugriffszeit von 17 ms).

Gemeinsam mit D.L.Murphy entwarf Bobrow ein LISP-System, das auf einemvirtuellen Speicherkonzept aufbaute [BO66a,BO66b,BO68a]. Dieses System ist vor allem wegen seiner Speicherverwaltungstechniken bekannt geworden.Es dürfte als Studienobjekt wesentlich das Betriebssystem TENEX [BO72] beeinflußthaben.

Bei dem extrem kleinen Speicher mußte man dafür sorgen, da\ssnur diewichtigsten Programme permanent im Speicher waren: Unterbrechungsbehandlung, Time-Sharing-Supervisor und Paging-System (4K). Ein Bereich von ebenfalls 4K Worten diente als Überlagerungsbereich für Interpreter und Laufzeitroutinen der compilierten Funktionen, für nicht-``kritische'' LISP-Unterprogramme zur Listenverarbeitung, Ein- und Ausgabeprogramme, Garbage Collection, Anfangsprogramm.

Um die compilierten Funktionen möglichst zeitgünstig abarbeiten zu können, war ein Ring-Puffer aufgebaut worden, der mittels eines {\emTransfer-Vektors} verwaltet wurde. Durch die begrenzte Größe des Ring-Puffers (3400 Worte) konnte es geschehen, da\ssein Programm, dasUnterfunktionen aufrief, durch diese aus dem Ring-Puffer gedrängt wurde. Um einer solch unangenehmen Situation vorzubeugen, sollten Funktionsgemeinschaften aufgebaut werden, d.h. Mengen von einander aufrufenden Funktionen ([BO66a], S.6).

Die Grundidee des virtuellen Speichers bestand in der Zuordnung von Adressenbereichen und Datentypen. Es sollte immer möglich sein, den Typ eines Objekts aus dem Zeiger abzuleiten, der auf dieses Objekt zeigt. Dazu dient die Aufteilung der Atomköpfe in {\tt PRINT-NAMES, PRINT-NAME-POINTERS, FUNCTIONCELLS, PROPERTY-LIST-CELLS} und VALUE-CELLS. Der Zeiger auf einAtom war der Zeiger auf die Wertzelle (VALUE-CELL). Aus diesem ließen sichdie anderen Teile ableiten.

Nur die großen Zahlen waren in einem Zahlenspeicherbereich dargestellt. Alle Zahlen zwischen -32767 und +32767 wurden direkt durch Zeiger dargestellt, so da\sseinerseits Vergleiche ohne Seitenzugriffe von der Trommel ausführbarwurden und andererseits Platz gespart wurde ([BO66a],S.11).

Bei der Konstruktion von Listenstrukturen verfuhr CONS nach heuristischenRegeln, um die Seite zu bestimmten, auf die eine neue Zelle kommen sollte ([BO66a], S.12). Das Garbage Collection bestand aus einem lokalen Verwalterfür die Seiten und einem anscheinend selten benutzten Dump-Programm für kompaktierte Strukturen [BO66c].

Mit diesen Festlegungen war das pdp1-LISP-System sicher ein interessantes System. Laufzeitmessungen ergaben starke Abhängigkeiten von den Datenstrukturen, so da\sseinProgramm zwischen 10\% und 50\% seiner Abarbeitungszeit auf die Trommel warten mußte ([BO66a], S.16ff). Offenbar waren die Erfahrungen mit denheuristischen Regeln für die Begrenzung der Streuung von Listenstrukturen über die Seiten so gut, da\sssie auch später beibehalten wurde. Es ist immernoch ein offenes Problem, ob ein konsequent kompaktierendes Garbage Collection oder ein CONS, das nach dem Bobrow-schen Ideen arbeitet, die bessereLösung ist. Messungen und konkrete Vergleiche liegen jedenfalls nicht vor.

Obwohl das pdp-1-LISP-System von BBN nichts mit dem System von Deutsch(vgl. S.199) zu tun hatte, war Deutsch doch an der Arbeit beteiligt. Erberiet Bobrow bei dem Entwurf der Kellerspeicherarbeit und schrieb eine derersten Compilerversionen [BO76]. Kurz danach sollte Deutsch erneut einLISP-System auf einem Rechner aufbauen, den etwas später auch Bobrow alsArbeitsrechner bekam.

1964--1965 wurde an der University of California in Berkeley aus der SDS930 die Seitenmaschine SDS940 entwickelt [PIRT66], die Time-Sharing angepaßt seinsollte. Deutsch, der zu dieser Zeit dort arbeitete, implementierte einLISP-System [DEU66]\footnote {Deutsch war mit der gesamten Arbeit inBerkeley verknüpft. Er beteiligte sich an der Entwicklung des Time-Sharing-Systems und vieler anderer Programme. Für den nicht ungerüsteten SDS930 hatte er ebenfalls ein LISP-System aufgebaut, das sicher wesentlich Pate stand für das System auf der 940 [DEU65}] und beschäftigte sich mitTextverarbeitung [MOE65] im Dialog. Auf Grund der in diesem Zusammenhanggesammelten Erfahrungen war er eine wichtige Stütze bei der Transferierung des BBN-LISP-Systems zur SDS940 und beim Entwurf des Software-Paging-Systems [BO76, DEU76].

Das oben erwähnte Vergleichsresultat machte LISP in den Kreisen der Programmierer, die sich mit nichtnumerischen Problemen beschäftigten, attraktiv. Durch den popularisierenden Artikel E.C.Berkeleys [BE64] und vorallem durch den Sammelband ``The Programming Language LISP: Its Operation and Applications'', der von Bobrow und Berkeley gemeinsam herausgegebenworden war [BB64], wurde LISP nicht nur in Amerika bekannt, sondern auch imAusland begann man auf diese Sprache und ihre Möglichkeiten aufmerksam zu werden. Obwohl im Laufe des Jahres 1966 an mehreren Stellen außerhalb der USA LISP-Implementationen begonnen worden waren, brachte die IFIP-Konferenz über Sprachen für die Symbolmanipulation in Pisa vom 5. bis 9.9.1966 den eigentlichen internationalen Durchbruch [BO68b].

W.L.van der Poels erstes LISP-System soll zu dieser Zeit schon funktionsfähiggewesen sein [POE78], J.Kents Diplomarbeit war fast fertigt -- das demLISP1.5 nachgearbeitete LISP-System auf der CDC3600 arbeitete. In Polen begann man nach dieser Konferenz mit der LISP-Implementierung.

In Pisa war nicht nur über spezielle Implementationstechniken gesprochen worden, sondern Programmsysteme zur Formelmanipulation, wie z.B. MATHLAB, wurden auch vorgestellt. Die Angaben C.Engelmans [ENG66] über dieBequemlichkeit der Arbeit mit LISP sprachen für sich und waren eine hervorragende Werbung. So dauerte es nicht mehr lange, und LISP wurde eine viel benutzte Programmiersprache.

 

Weltweite Verbreitung von LISP 1966--1978

In den Jahren nach 1966 hat sich die LISP-Szene gewandelt. Während vorher die Entwicklung gekennzeichnet war durch die Ausbreitung von LISP auf immer neue Rechner bei Beibehaltung der wesentlichen Grundeigenschaften sowie der wachsenden Ausnutzung bzw. der Aneignung der Charakteristika der Sprache und der Aussöhnung mit der Sprachform, kann man nun zwei recht verschiedene Formen der Weiterentwicklung unterscheiden:

Einerseits finden wir zu einem Gutteil die bisherige Ausbreitung auch weiterhin: neue Implementationen für bereits verwendete oder andere Rechner werden nach wie vor aufgebaut; neue Anwendergruppen initiieren die LISP-Implementierung in ihrer Arbeitsumgebung. Hier sind nun die geographischen Dimensionen ausgeweitet -- Europa und Japan werden von LISP erfaßt.

Andererseits kann man die fortgeschrittenere Form der LISP-Entwicklung nun deutlich in Linien aufteilen. Obwohl möglicherweise jedes LISP-System von anderen verschieden ist, gibt es doch klar abgrenzbare Gruppen die von einem Leitsystem angeführt werden. Die Fortentwicklung des Leitsystems wird über Jahre hinweg vorangetrieben durch einen jeweils gleichbleibenden Stamm von Systemprogrammierern und -Pflegern. Wo diese ihr Interesse verlieren bzw. den Arbeitsplatz wechseln, hört die Weiterentwicklung des Leitsystems auf bzw. wird in seltenen Fällen von anderen übernommen.

Es ist recht schwierig, aus der Fülle des Materials das auszuwählen, was nicht nur auf lokale Programmverbesserungen bzw. -ausweitungen durch Erweiterung der Funktionsbasis reduzierbar ist, sondern das das Äußere der Sprache formt. Nun ist der Übergang hier in LISP sicher fließend (und ist es tendenziell immer in der Programmierung) -- man kann ja mit einigem Recht LISP als Programmiersystem, als bloße Sammlung von Basisfunktionen verstehen.

Doch kann man auch die natürliche Sprache nicht einfach als Vokabelsammelsurium abtun. Ob die Programmiersprache durch den syntaktischen Zucker verkörpert wird bzw. wesentlich durch ihn geprägt wird, erscheint, um das andere Extrem auszusprechen, ebenfalls recht fraglich. Ob demnach ``echte'' Sprachentwicklung notwendig von Wortschatzerweiterungen abzutrennen ist und für Programmiersprachen notwendig neue syntaktische Ausdrucksmittel anbieten muß, ist wiederum recht problematisch.

Dennoch wollen wir versuchen, diejenigen Funktionsneuschöpfungen, die nur eine Komplettierung gewisser Grundmengen sind (etwa die Aufnahme der trigonometrischen Funktionen) von solchen zu trennen, die eine gewisse Änderung im Sprachverständnis und -gebrauch zum Ausdruck bringen. Nur diese letzteren werden Aufmerksamkeit verdienen.

Ebenfalls wird so manche Verbesserung in der Implementierungstechnik nicht erwähnt werden können. Die damit die zusammenhängende mühevolle Arbeit wird allerdings damit nicht genug gewürdigt.

Um die durch die Leitsysteme linienweise vorangetriebene Fortentwicklung der Sprache über diese Linien hinweg zu systematisieren, sollen folgende wichtige Triebkräfte genannt werden:

  1. Die tägliche Verwendung der Sprache führte zu Bedürfnissen bezüglichTesthilfen, automatischen Fehlerbeseitigern, Unterstützungssystemen für die Arbeit mit großen Datenbeständen von LISP-Programmen und anderen Hilfsmitteln für die interaktive Dialogarbeit.

     

  2. Die sich gleichzeitig entwickelnde Wissenschaftsdisziplin KünstlicheIntelligenz (McCarthy: ``Die Wissenschaft sollte Cognology heißen, dasZiel ist, Programme zu entwickeln, die künstliche Intelligenz zeigen'' [MCC77]) führte zu neuen Problemstellungen, zu deren Lösung die Forscher neueFormulierungs- und Bewältigungsmittel verlangten [BO73b]. Obwohl LISP nichtnur im Kern unverändert blieb, hat man durch einige Erweiterungen diese Forderungen befriedigen können. Andere sind offen geblieben oder innerhalb der sogenannten höheren Programmiersprachen, die auf LISP aufbauen, befriedigt worden.

     

  3. Die Verwendung von LISP für die Implementierung großerFormelmanipulationssysteme, die teilweise von den aktivsten LISP-Pflegern vorangetrieben wurde und wird, führte zu Widersprüchen zwischen der Eignung von LISP für die Symbolmanipulation und der für die numerische Rechnung. Daneben mußten diese Forscher ihren Kunden, d.h. den eigentlichen Anwendern, den Physikern und Ingenieuren, die LISP nicht kannten, Hilfsmittel bieten, die in mancher Art eine Weiterführung der Nutzerhilfsmittel aus a) darstellen.

     

  4. Ein ``großes Thema'' der LISP-Weiterentwicklung ist die Verwendungdieser Sprache für die Implementierung anderer Programmiersprachen. Hat sich auch der Akzent von den erweiterbaren Sprachen [BO64d] etwas entfernt, soblieb die Tendenz doch bestehen. LISP hat von diesen Projekten insofern profitiert (neben dem offensichtlichen Nutzen, verwendet worden zu sein), da\ssmancherlei Konzepte aus den höheren Sprachen in die Basis herübergedriftet sind.

Wir werden die Metasysteme in Abschnitt 4.8 behandeln.

Um das Material zur LISP-Geschichte dieser 12 Jahre zu ordnen, werden die Entwicklung von LISP für sich behandelt, soweit dies möglich ist und die Entwicklung durch das Leitsystem geprägt wird. Im übrigen wird geographisch vorgegangen. So behandeln wir Europa, Japan und andere Länder getrennt von den USA.

 

MacLISP

Durch die Anfragen des Autors angestoßen, hat der langjährige LISP-Experte J.L.White eine Arbeit über die Entwicklung von MacLISP veröffentlicht, soda\sshier das wesentliche historische Material verfügbar ist [WHI77].

Anfang 1966 verfügte man am MIT über zwei LISP-Systeme: Das ständig weiter verbesserte LISP1.5-System im CTSS, das auf einer IBM7094 lief, und das neue LISP1.5-System auf der pdp-6. In der Zeit zwischen 1965 und 1966 hatte ein Wechsel der Mitarbeiter stattgefunden. Außer Minsky waren beinahe allebisherigen Forscher vom MIT abgegangen oder hatten in andere Bereiche gewechselt. Dafür arbeiteten nun {\sc Moses, Martin, Greenblatt, Nelson, P.Samson, Teitelman} und andere an der LISP-Implementation. Im Labor für Künstliche Intelligenz begann sich deutlich eine Gruppe von Forschern abzusondern, die sich für Formelmanipulation interessierte.

Durch die Erfahrungen mit großen LISP-Programmsystemen angeregt und durch die Erarbeitung des neuen Compilers (für die pdp-6) sicher angestoßen, begann man über die Idee zu diskutieren, die Bindung der Variablen mit Hilfe der Assoziationsliste aufzugeben und, ähnlich wie in den blockorientierten Programmiersprachen, ein Kellerspeichermodell zu verwirklichen. Nach {\sc White} [WHI77][S.2] war es Greenblatt, der die Idee\footnote{Merkwürdigerweise wird das M460-LISP als Vorläufer völlig vergessen. Die Beziehungen von Evans} zu den LISP1.6-Implementatoren sind unklar. hattein Anlehnung an FORTRAN zu verfahren: Die aktuellen Variablenwerte wurden dezentral in die Atomrepräsentation eingefügt und damit jegliche Suche nach dem Wert unnötigt. Die alten Variablenwerte wurden zentral in einem besonderen Kellerspeicher gerettet, dem Special-Push-Down-Stack.

Es ergaben sich bemerkenswerte Geschwindigkeitsvorteile des neuen Verfahrens. Demgegenüber konnte man das FUNARG-Modell zur Behandlung globaler Variablernicht mehr vollständig verwirklichen. Doch das schien vorerst keine wesentliche Einbuße.

Vermutlich ist man von der Arbeit der compilierten Funktionen ausgegangen. In dem komplizierten Durcheinander von APVAL, COMMON- und SPECIAL-Variablenwurde viele Arbeit parallel ausgeführt und jemand, der die gesamte Systemarbeit gut übersah, konnte leicht feststellen, da\sseigentlich nur einsolcher Typ erforderlich war. Man benutzte zunächst den wichtigsten: Alle interpretierten und freien compilierten Variablem wurden automatisch als SPECIAL-Variablen aufgefaßt; damit war vollständige Kommunikation zwischencompilierten und interpretierten Funktionen gesichert.

Die Implementation dieses Verfahrens hat zunächst den Nachteil, da\ssallzuviele SPECIAL-Variablen auftreten, wenn vorher interpretiert wird.Auch die Darstellung der Wertzelle (SPECIAL-Zelle) als Element der P-Listebrachte Nachteile mit sich, obwohl sie teilweise durch die pdp-6-Wort-Struktur erzwungen war: Wenn die P-Liste verändert wurde, konnte eine kleine Suchoperation in dieser Liste erforderlich sein. Es ist üblich geworden, ein LISP-System, das mit dieser Art der Variablenbindung arbeitet ( shallow access nach Moses [MOS70]), als LISP1.6 zu bezeichnen.

Natürlich enthielt das erste LISP1.6-System, das etwa im Juni 1966 funktionsfähig war [SAMS66], viele weitere Änderungen. Für den Benutzer vielwichtiger als die Frage der Variablenbindung dürfte zunächst die Bequemlichkeit gewesen sein, die das neue System bot, die Menge der Funktionen und die Dienste, die es bereitstellte.

Nachdem das System offenbar durch weitere Stufen der Verbesserung gegangen und teilweise stark überarbeitet worden war [PDP6a], scheint Anfang 1967eine gewisse Stabilität eingetreten zu sein [PDP6b,PDP6c]. Im wesentlichen hatsich diese Version bis etwa 1970 gehalten [WHI70].

Typische neue Funktionen im pdp-6-LISP waren die zusammengehörigen Funktionen mit beliebig vielen Argumenten und mit zwei Argumenten APPENDund *APPEND, GREATERP und *GREAT, LESSP und *LESS usw., die Zeichenmanipulationsfunktionen EXPLODE und EXPLODEC als Parallele zu den Druckfunktionen PRINT1 und PRINC, die Ein- und Ausgabefunktionen UREAD, UWRITE, UFILE und UKILL, die Mehrzweckfunktion BOOLE (schließt LOGAND, LOGOR, LOGXOR usw. ein)und die Funktionen für die P-Listenarbeit DEFPROP, REMPROP,PUTPROP, GET und GETL.

Vom pdp-1-LISP übernommen wurde der Slashifier, d.i. ein Zeichen(zuerst ``/'', der Slash), das dafür sorgte, da\ssdas nächste Zeichen alsBuchstabenzeichen und dadurch als zulässiger Bestandteil eines LISP-Atoms betrachtet wurde. Damit wurde die alte \$-Klammer des LISP1.5 und alle Arten von symbolischen Ausgabeströmen des Systems wieder einlesbar gemacht.

Das Jahr 1967 war gekennzeichnet durch die Entwicklung des pdp-6-Betriebssystems durch das AI-Laboratorium [EAS72] und den Wechsel vonCTSS zu MULTICS im MIT Rechenzentrum [COR65]. Die Bearbeiter des LISP1.6Systems, zu denen inzwischen White gestoßen war, sahen sich damitzunächst vor die Aufgabe gestellt, die Beziehungen zum Betriebssystem zu klären und in möglichst günstiger Form zu gestalten. So erreichte man, da\ssdasLISP-System innerhalb und außerhalb des Time-Sharing-Systems laufen konnte; man sorgte für Anschlüsse an andere Programmiersprachen, insbesondere an Assemblerprogramme [SILV 67]. Die umfangreichste Arbeit bezog sich jedochauf neue Ein- und Ausgabemöglichkeiten, wobei sowohl neue Geräte (Fernsehkameras, Plotter, Displays) als auch verbesserte Zugriffsmöglichkeiten bereitgestellt wurden.

Die Gerätetechnik erreichte Anfang 1968 durch die Lieferung der pdp-10 und die Inbetriebnahme von MULTICS auf der GE634 einen Stand, der für Jahre gleich bleiben sollte. Am AI Laboratorium wurde die Entwicklung des incompatiblenTime-Sharing-Systems ITS abgeschlossen, das den großen Anforderungen der Arbeit mit Robotern und Visionssystemen gewachsen war.

Für die GE634 wurde schon 1967 ein erstes LISP-System [YO67] durch {\sc J.C.Yochelson} im Rahmen seiner BS-Graduierung entwickelt. Die mit diesem System gewonnenen Erfahrungen insbesondere bezüglich der Speicherverwaltung [FEN69]waren wichtige Voraussetzungen für das spätere System, das mit dem pdp-10-System vollständig kompatibel wurde.

Nachdem nun die Umgebung für die LISP-Systeme einigermaßen stabil war, begann eine neue Etappe der Entwicklung der Sprache am MIT. Die treibenden Kräfte waren dabei die Wissenschaftler, die am Aufbau des Formelmanipulationssystems MACSYMA arbeiteten ({\sc Moses, Martin, R.J.Fateman, J.P.Golden} und eine Reihe Studenten), sowie diejenigen, die über neue Programmiersprachen für die Formulierung von Problemen der Künstlichen Intelligenz nachdachten ({\sc C.E.Hewitt, G.J.Sussman, T.L.Winograd, I.P.Goldstein, V.Pratt, Greenblatt} und T.L.Binford und ebenfalls einige Studenten).

Die erste wesentliche neue Idee, die im Zusammenhang mit den derzeit vieldiskutierten ``erweiterbaren'' Sprachkonzepten stand, war die Einführung der Makrozeichen. Jedem Zeichen kann ein Programm zugeordnet werden, dasnormalerweise irgendwie weitere Zeichenfolgen einliest und als Ergebnis einen Ausdruck liefert, der für das Makrozeichen und die abschließende Zeichenfolge verwendet wird. Das entsprechende Programm ist selbstverständlich in LISP notiert. Durch diese von White vorgeschlagene und verwirklichteKonstruktion wurde LISP zu einer dynamisch syntaktisch veränderbaren Sprache. Einfache Verwendungsmöglichkeiten betrafen das ' als Quote-Zeichen,das / als Slashifier und wenig später die Verwendung der Präfixzeichen inSussmanns MICROPLANNER-Implementation [SUS70]. Zur gleichen Zeit fügteWhite auch die variable Basis für ganze Zahlen ein, so da\ssdiese Zahlensich auf Basen zwischen 2 und 36 beziehen konnten.

1968 begann man mit den Planungen für zwei wesentliche Neuentwicklungen, die dann Schritt für Schritt verwirklicht wurden: Mindestens bis 1969 überall und seitdem außerhalb des MIT immer noch fast überall war man die Meinung, da\ssLISP lediglich für nichtnumerische Probleme tauglich sei und da\ssgelegentlich numerische Berechnungen zwar möglich seien, aber mit unverhältnismäßig hohen Verweilzeiten bezahlt werden müßten. Für die Entwicklung des MACSYMA-Systems, das nach symbolischen Vereinfachungen anFormeln auch deren numerischen Auswertung erlauben sollte, war das damalige Verhältnis zur Abarbeitungsgeschwindigkeiten von Programmen, die in FORTRAN geschrieben worden waren, ein ernstes Problem (White [WHI77] spricht von1:100).

So ging man daran, bessere arithmetische Möglichkeiten bereitzustellen.

Die interne Repräsentation der Zahlen wurde, ausgehend von der LISP1.6-Konzeption (Zahlen haben ähnliche Struktur wir literale Atome), um zwei Drittel des Platzes verkleinert (Martin 1969). Die vorübergehendeingeführten kleinen ganzen Zahlen (in LISP1.6 als INUM bezeichnet) wurdender Einheitlichkeit wegen von White wieder beseitigt.

Eine ganze Reihe neuer arithmetischer Grundfunktionen wurden aufgenommen. Hierbei handelte es sich sowohl um neue Versionen bereits existierender Funktionen, die wegen der vorausgesetzten Typenreinheit (nur ganzen Zahlen oder nur Gleitkommazahlen) schneller arbeiten, als auch um völlig neue (Quadratwurzeln, größer gemeinsamer Teiler usw.).

Für die Arbeit am Compiler entscheidend wurde die Idee von Binford, fürdie numerischen Zwischenergebnisse zwei (je für ganze und Gleitkommazahlen) Kellerspeicher einzuführen. Golden und E.C.Rosen begannen 1969den Compiler für die Erzeugung guten Codes für numerische Programme umzuformen. Deklarationen sollten helfen, Typabfragen zur Laufzeit zu beseitigen; die inzwischen geschaffenen Datendarstellungen, die Zahlenkellerspeicher und die auf ihnen aufbauenden Aufrufbefehlsfolgen für numerische Unterprogramme sorgten insgesamt dafür, da\ssder neue Compiler Code generierte, der mit dem von einem FORTRAN-Compiler generierten Code vergleichbar war [FAT71].

Eine frühe Version dieses Compilers lief 1971 [GOE70], er wurde durchOptimierungsteile von White ergänzt -- eine Arbeit, die etwa Ende 1976abgeschlossen war. Überhaupt wurde in dieser Zeit der Compiler -- als das zweite wichtigste Projekt neben der Verbesserung der arithmetischen Basis -- wesentlich verändert und überarbeitet.

Um die Bemerkungen zu den Entwicklungen dieses ersteren Projekts zu beenden, mu\ssnoch der Aufbau der Arithmetik für beliebig große (bzw. beliebig genaue)ganze Zahlen erwähnt, von D.E.Knuth [KN69] übernommen.

Bis 1967 war der Compiler, wie noch heute in verschiedenen LISP-Systemen, vollständig in LISP geschrieben gewesen. Er lieferte eine Liste von Assemblerbefehlen, notiert in einer Listenform, kurz LAP genannt. HatteWhite dieses Programm schon 1967 überarbeitet, so da\ssman die LAP Listenauf externen Speicher auslagern konnte und im Bedarfsfall in Maschinencode umformen konnte [WHI67], so war dieses Format immer noch viel zuschwerfällig. Außerdem war der vom Compiler gelieferte Code durchaus verbesserungsfähig.

Der Anfang wurde schon 1967 von W.Diffie gemacht, der den Compiler inAssembler umschrieb und statt der umständlichen Listenarbeit Tabellen einbezog [GOE70]. Parallel zu den Arbeiten an dem Compiler für die schnelleArithmetik wurde große Mühe auf die Optimierung des Objektcodes verwandt, und sorgfällig wurden alle Fehlermöglichkeiten überprüft und etwa gefundene Mißstände beseitigt. Golden, White und Rosen erarbeiteten auf der Basiseines von White entworfenen Schemas für dynamische Felder ein neues Formatfür verschiebliche Objektmoduln (d.h. Maschinenprogramme mit einigen Ladezeit einzusetzenden Adreßverbindungen). Als das Ladeverfahren, welches dieses Format verwendete (G.L.Steele und White), zwischen 1972und 1973 arbeitsfähig war, sanken die Verarbeitungszeiten wesentlich. White [WHI77] berichtet über die Verminderung der Ladezeit des gesamtenMACSYMA-Systems von einer Stunde auf 2 Minuten. Kurz darauf wurde das neue Ladeverfahren ergänzt durch die Möglichkeit, Programme automatisch erst im Bedarfsfall nachzuladen.

Beachtet man die Zeitersparnisse, so kann man sich leicht vorstellen, wieviel mehr Anwendungsmöglichkeiten diese Änderungen mit sich brachten. Während die durch Anforderungen durch das MACSYMA-System vorgenommenen Änderungen und Erweiterungen vornehmlich die arithmetische Basis betrafen, so kamen von den Programmsystemen für die künstliche Intelligenz Hinweise auf wünschenswerte Erweiterung der Kontrollstrukturen.

Schon 1969 hatte Sussman parallel zu Lösungen, die das BetriebssystemMULTICS anbot, ähnliches für LISP gefordert: Unterbrechungsmechanismen wie Kontrollzeichnen, Alarmuhren, Interprozeßkommunikation und Ausnahmebedingungen ([WHI77], S.2). Etwa zur gleichen Zeit wie BBN-LISP (vgl.Abschnitt 5.2) wurden entsprechende Hilfsmittel implementiert. Mit der Zeit wurden die Forderungen präziser, und man erkannte Gefahren in den verwendeten Routinen zur Unterbrechungsbehandlung (Schutz von in LISP eingebetteten Programmsystemen vor unerwünschten, nur für LISP interessanten Unterbrechungen u.ä.) Die derzeit letzte Überarbeitung nahm Steele Ende1973 vor.

Im Zusammenhang mit der CONNIVER-Implementierung durch Sussman entstanddas Verlangen nach nichtlokalen Sprüngen. Da sich dieser Wunsch auf Hilfsmittel beschränkte, eine im Ablauf befindliche Berechnung abzubrechen, schlug White 1972 Sprachelemente für globale Exits vor. Mittels derFunktion CATCH wird nun ein Verschachtelungsniveau mit einer Markeversehen, zu dem man von einer beliebigen Stelle innerhalb dieses Niveaus zurückkehren kann (THROW).

Um die Hierarchien der ineinander enthaltenen Programmsysteme (etwa: 1. LISP, 2. CONNIVER in LISP, 3. Problemprogramm in CONNIVER) sorgfältig zutrennen, wurde 1971 durch White und Sussman die Objektliste (Liste alleAtomsymbole) zu einem auswechselbaren Feld umgeformt (OBARRAY). Damitwurden Konfliktmöglichkeiten zwischen Namen in den verschiedenen Programmebenen beseitigt. Weitere hiermit verknüpfte Änderungen ermöglichten es den Nutzer, Grundhandlungen des LISP-Systems (wie etwa den Verarbeitungszyklus) völlig zu ändern und ihren Erfordernisse anzupassen [WHI77].

Durch die Erweiterungen anderer LISP-Systeme angeregt, hat man MacLISP, wie man die Sprachversion seit etwa 1970 nannte, weitere Änderungen erfahren. Zu nennen sind hier Einflüsse von STANFORD LISP1.6 [QA72a] auf den Entwurf des Programmssystems für die dynamische Veränderungen der Ein- und Ausgabequellen ([WHI77], S.4), das später allerdings nach demMULTICS-Vorbild (NEWIO) umgestaltet wurde (Steele ca. 1975).

Auch InterLISP hat Anregungen für Verbesserung geliefert durch ..?.. eines BREAK-Zustandes imFehlerfall und nach programmierter Unterbrechung, in dem wie im normalen Verkehr mit dem System (im Hauptniveau) Auswertungsdialoge abgewickelt werden können. Mit den InterLISP-Test- und Edierhilfen (die ja auch in LISP notiert sind) vergleichbare Programme wurden nach und nach erstellt und praktisch für jeden Nutzer zugreifbar.

Bis 1971 arbeitete jedes Programm in einem starren Adreßraum, der von der Maschine vorgegeben war. Die Aufteilung dieses Raumes unter die verschiedenen Datentypen war nicht veränderbar. Während der Entwicklung von MICROPLANNERverlangte Sussman Möglichkeiten für {\em intelligente dynamischeSpeicherverwaltung}, und White führte 1971 erweiterbare Teilräume ein. MitHilfe von programmierbaren Parametern für das Garbage Collection konnte der Nutzer obere Grenzen für die Teilräume einführen und angeben, wieviel freier Platz mindestens verfügbar sein muß.

1972 wurde dies durch den GC-Dämon gelöst -- ein Programm das unmittelbar nach jedem Garbage collection aufrufen wird und dadurch die Verwendung der Speicherbereiche durch passende Änderung der Parameter überwachen und steuern kann.

Wesentlich verbessert wurde die Speicherplatzverwaltung durch die konsequente Seitenorientierung, ein Konzept, das von InterLISP übernommen wurde. 1973 wurden von White, Steele und S.Macracis die Pläne dazu entworfen, und 1974 programmierte Steele die entsprechenden Routinen. durch dietypenreinen Seiten wurde nicht nur ein verbessertes Verhalten bei der Speicherexpansion erreicht, sondern es wurde auch möglich, Seiten, die unveränderliche LISP-Daten bzw. -programme enthielten, für die mehrfache Benutzung freizugeben.

Wenn heute mehrere Benutzer gleichzeitig z.B. mit MACSYMA arbeiten, mu\ssnicht jeder für sich die MACSYMA-Programme laden. Sie sind nur einmal im Speicher und durch eine Schreibsperre vor Veränderungen geschützt. Dadurch wird die Häufigkeit der Fälle, wo Seiten nachgeladen werden müssen (page faults) wesentlich herabgesetzt. Hinzu kommt, da\ssder Garbage Collector diese Seiten ignorieren kann, da von ihnen aus keine Zeiger in die dynamisch veränderlichen Teile gehen können.

Etwa 1970-71 trennte sich Martin von der MACSYMA-Gruppe und begann mitseinen Arbeiten zur automatischen Programmierung. Da er nun wesentlich auf das MULTICS-System angewiesen war, wünschte er sich ein LISP-System, das völlig mit dem auf der pdp-10 laufenden MacLISP verträglich ist. So wurde etwa Ende 1971 durch D.P.Reed die MULTICS-Version begonnen und 1973abgeschlossen. Zum Schlu\sssoll neben anderen auch D.A.Moon beteiligtgewesen sein.

Ähnliche Situationen waren schon vorher aufgetreten. Immer wenn ein Mitarbeiter das MIT verließ, wünschte er sich die alte Arbeitsumgebung. Da aber die Betriebssysteme auf den pdp-10 verschieden waren, scheiterte das Bemühen um den Export des MacLISP-Systems. Allerdings war in vielen Fällen auch der Rechner zu klein, denn, wie White [WHI77] angab, benötigteschon 197? allein der Compiler 65K Worte!

Im Sommer 1973 wurde ein neuer Anlauf genommen, um MacLISP wenigstens innerhalb des vom Hersteller des pdp-10 gelieferten Time-Sharing-Systems TOPS-10 verfügbar zu machen. Gemeinsam mit Angestellten des Worcester Polytechnical Computation Centers und des Computer Science Departments der Carnegie Mellon University wurde dieses Projekt erfoglreich beendet.

Sogar eine Einlagerung in das für InterLISP verwendete Betriebssystem TENEX gelang 1971, allerdings fanden sich keine Nutzer.

So ist MacLISP gegenwärtig in drei wesentlich verschiedenen Umgebungen anzutreffen: Im AI-Laboratorium läuft es unter dem Betriebssytem ITS auf der pdp-10 (heute:DEC-10), im MATHLAB (MACSYMA-Gruppe), und außerhalb des MIT läuft es unter Tops-10 (eine leicht abgeänderte Version arbeitet im Time-Sharing-System des AI-Laboratoriums der Stanford University) ebenfalls auf der pdp-10, und außerdem ist es auf der Honneywell H6180 unter dem System MULTICS verfügbar.

MacLISP verfügt über eine große Zahl von implementierten Grundfunktionen (über 220), unter denen vor allem die Vielfalt der arithmethischen Funktionen auffällt. Durch eine recht große Anzahl von Funktionen kann der Nutzer auch in die Arbeit des Interpreters eingreifen, in direkte Kommunikation mit dem Basisbetriebssytem treten und die umfangreiche Menge von peripheren Geräten nutzen [MOO74].

Die Betriebssysteme, die dem Nutzer den virtuellen Speicher verwalten und ihm damit nahezu unbegrenzt Platz offerieren, bringen durch die vielen Möglichkeiten, die sie bieten, allerdings auch verlangsamende Effekte ins Spiel.

Die Time-Sharing-Umgebung ist für eine Rechnung, in der unverhältnismäßig viel Hauptspeicherplatz benötigt, in mancherlei Hinsicht wieder ungünstig. Das bewog die Wissenschaftler am MIT, eine Maschine zu planen und zu bauen, die LISP auf dem Maschinenniveau abarbeitet und einen größeren Adreßraum bietet als die pdp-10. Diese LISP-Maschine, die etwa MacLISP entspricht, arbeitete 1977 [GREL74, BAW77].

Daneben wird MacLISP auch auf konventionellen Art weiterentwickelt. Für die neue Generation der Rechner der Firma DEC, für die VAX11/780, wird ein LISP-System entworfen, das auf den mit MacLISP gemachten Erfahrungen aufbaut. Um die neuen Ideen zum Ausdruck zu bringen, nennt man dieses im Entstehen (1978) begriffene System NIL, d.h. neue Implementation von LISP. Wie manhört, soll dieses System etwas maschinenunabhängig sein, um den Transport auf andere Anlagen zu vereinfachen, und dem LISP-Dialekt der Greenblattschen LISP-Maschine nachgebildet sein.

 

InterLISP

Bei BBN hatte man gerade genug Erfahrungen mit dem Software-Paging auf der pdp-1 sammeln können (vgl. Abschnitt 4.8), als Mitte 1966 die neue Maschine SDS940 eintraf. Diese war nicht nur dreimal so schnell wie die pdp-1, sondern hatte mit 24 Bit pro Wort und einem physischen Speicher von 64K Worten auch mehr Platz.

Der Rechner war für Time-Sharing-Aufgaben gebaut und bot eine begrenzte Unterstützung für einen kleinen virtuellen Speicher. Bobrow undMurphy entschlossen sich, über diese durch die Hardware gegebenenMöglichkeiten hinaus erneut, wie beim pdp-1, ein Software-Paging-System aufzurichten. Dieser virtuelle Adreßraum sollte 2048 K Worte gro\sssein, also benötigte man 21 Bit.

Ansonsten war das neue LISP-System dem alten auf der pdp-1 nachgebildet. Aufteilung der Atome in Wertzelle, Funktionenszelle, P-Liste und P-Namenzeiger wurden wieder übernommen, das ``smarte'' CONS, das dieZertreuung über die Seiten aufhalten sollte, blieb, usw. usf.

Auch der kompatible (weil ohne SPECIAL-Deklarationen jede Funktionübersetzt werden konnte) Compiler wurde übernommen, wobei wiederum Deutsch mit Bobrow kooperierte. (Deutsch beriet außerdem dieImplementierungsgruppe, zu der noch L.Darley gehörte, bei dem Entwurf desSoftware-Pagers.)

Sein besonderes Gesicht bekam dieses LISP-System allerdings durch die Nutzerhilfen, die nicht, wie in anderen Systemen dieser Zeit, als bloße Anhängsel in LISP-Form verfügbar waren, sondern die in das System tief integriert waren (obwohl Teile sicher in LISP notiert waren). Verantwortlich für diese Neuerung war W.Teitelman. Dieser hatte, wie bereits erwähnt, einigenAnteil an der Entwicklung des pdp-6-LISP am MIT. Er beschäftigte sich schon früh mit der Programmiertechnologie und entwarf Programmsysteme zum Fehlersuchen und Überwachen von LISP-Programmen [TE65a]. Durch dieEntwicklung des formatierten Listenverarbeitungssystems FLIP [TE65b] wollteer die Listenverarbeitung einfacher und populärer machen.

Nachdem Teitelman im September 1966 mit einem System zur interaktivenProgrammentwicklung [TE66] promoviert hatte, wechselte er zu BBN. Dort wirkteer sofort wesentlich am Entwurf und an der Programmierung des im Entstehen begriffenen Systems für die SD940 mit. Neben der Arbeit am Interpreter und vor allem an den Fehlermaßnahmeprogrammen, Protokollierungsfunktionen und Unterbrechungssystemen hat Teiltelman einige große Teilsysteme aufgebaut,die die Arbeit des LISP-Anwenders wesentlich erleichtern sollten.

Unter diesen ist an erster Stelle der strukturorientierte Editor zu nennen Die Idee dazu hatte Deutsch, der wohl auch eine erste Version lieferte.Teitelman hat ihn aber wesentlich neu programmiert, als das LISP-SystemEnde 1966 arbeitsfähig war. Später ergänzte Teitelman die Nutzerhilfen durchein verbessertes FLIP [TE67] und durch das Subsystem {\tx DWIM} (Do what Imean) zur automatischen Beseitigung von Fehlern. Dieses bei komplizierterenFehlern allerdings interaktive System wurde 1968 ins BBN-940-LISP aufgenommen und diente hauptsächlich zur Behandlung von Abloch- bzw. Tippfehlern.

Mitte 1967 konnte das System auf der SDS940 den Nutzern übergeben werden; Teitelman verfaßte ein Manual [BO67].

Die nächste Etappe begann mit dem Kauf einer pdp-10 durch BBN. Wieder wurde, diesmal ausgehend vom SDS940 LISP, ein aufwärtskompatibles System entworfen. An diesem Akt waren neben Bobrow und Murphy jetztauch A.K.Hartley und Teitelman beteiligt; die Hauptarbeitbei der Implementierung trug Hartley unter der Mithilfe Murphys. Sie übertrug nicht nur die Programme, sondern modifizierte den Compiler so, da\sser Maschinencodefür die pdp-10 generierte. Das neue System wurde BBN-LISP genannt [TE71].

Basis des Systems war (und ist) das Time-Sharing-System TENEX [BO72], das aufdem (im Maschinenniveau leicht veränderten) Hardware-Paging der pdp-10 beruht und einen virtuellen Speicher von 256k Worten verwaltet. Im Unterschied zu den vorherigen Systemen genügte nun ein Maschinenwort für die Aufnahme einer ganzen LISP-Zelle. Obwohl der theoretisch verfügbare Speicher sank (auf 512K Zeiger), war praktisch mehr zugreifbar, da auf der SDS940 mit Großenordnungen von 96K gearbeitet worden war.

Später haben Wegbreit und J.W.Goodwin eine Art von separatemvirtuellen Speicher für compilierte Programme hinzugefügt -- den Swapper.Damit wuchs der Raum für die in dieser Form vorliegenden Programme auf 128 Millionen Worte.

Neu bei der Umstellung auf die pdp-10 war, da\ssinzwischen bereits eine großeMenge von LISP-Programmen vorlag. Viele von diesen waren ausgesprochene Systemprogramme, die unbedingt in das neue System übernommen werden mußten. Um der unübersehbaren Arbeit des Umschreibens aus dem Weg zu gehen, wurde ein LISP-Programm, TRANSOR, von Goodwin aufgestellt, das diese Überführungausführte. Später wurde TRANSOR erweitert, so da\sses LISP-Programme ausanderen LISP-Dialekten, wie z.B. LISP1.5, STANFORD LISP1.6 usw., in InterLISP überführen konnte.

Das LISP-System stellte nun eine derartige Basis dar, da\ssman auch dieNutzerhilfen weiterentwickelte. So wurde das Subsystem DWIMweiterentwickelt und die Systeme Programmer's Assistant [TE72b] undCLISP [TE76], d.h. Conversational LISP, in das System aufgenommen.Bobrow stellte 1971 einen Blockcompiler fertig, der Gesamtheiten vonLISP-Programmen günstiger übersetzt als der normale Compiler. Sehr oft hat man es ja mit Systemen von LISP-Programmen zu tun, die nur untereinander abhängig sind und von außen nur über eine Hauptfunktion angesprungen werden. Hier bringt die lose Aneinanderfügung durch den normalen LISP-Compiler und die Verwaltung der Funktionen über einen Ring-Puffer bei knappem Speicherplatz Problem mit sich. (Die übergeordnete aufrufende Funktion wird durch die gerufene Funktion verdrängt). Durch die Einführung schneller und enger Verbindungen zwischen den Funktionen im Funktionenblock und durch die Möglichkeit, globalen Variablen nur einmal -- nämlich bei Eintritt in den Block -- im Kellerspeicher anordnen zu müssen, wird wichtige Zeit gespart. Selbst die Abarbeitung einer einzelnen rekursiven Funktionen wird vereinfacht, wenn sie durch den Blockcompiler übersetzt wird ([TE71], S.18, 17).

BBN-LISP wurde bald ein sehr bekanntes und begehrtes System. Besonders die vielen Test- und Arbeitshilfen waren sehr attraktiv für Implementatoren anderer LISP-Systeme. So nimmt es nicht Wunder, da\ssbald schon der Versuchgemacht wurde, diese Teilsysteme in andere existierende LISP-Systeme zu integrieren. Einen bekanntgewordenen Vorsto\ssin diese Richtung stellt UCI LISPdar [BOB73]. Der Aufbau diese Systems wurde 1971 gestartet, indem einSTANFORD LISP1.6-System [QA72a] überarbeitet und aus der Sicht von BBN-LISPin eine neue Umgebung gestellt wurde. Umfangreiche Arbeiten waren zu erledigen, um die Programme reenterabel zu machen; dadurch wurde die Aufteilung in einen mehrfach verwendbaren Programmteil (sharable) von 15K Worten und in einen nutzerspezifischen Teil von 8K Worten möglich. Da der Führer dieses Projekts ein Bruder D.G.Brobows war ({\sc Rusty Robert J.Bobrow}), war für gute Verbindung zu BBN gesorgt -- {\sc Bobrow, Teiltelman, Goodwin} und Hartley halfen durch viele Ratschläge. Diffie sorgte von Stanford aus dafür, da\ssdas Programmiererteam {\sc R.J.Bobrow, R.R.Burton, J.M.Jacobs} und D.Lewis keine offenen Fragen zumLISP1.6-System hatte.

UCI-LISP ist nun gekennzeichnet durch die günstige Speicherverwendung dank des reenterablen Codes, durch die einfachen Möglichkeiten, ständig die Speicherbereiche neu aufzuteilen, durch Erweiterung der LISP-Funktionen und Aufnahme der interaktiven Fehlersuch- und -beseitigungsprogramme von BBN. (Weitere Verbesserungen betrafen Ein- und Ausgabeprogramme.)

Interessant ist beim Studium des Fertigstellungsberichts von UCI-LISP festzustellen, da\ssin vielen Teilen des STANFORD LISP 1.6 Fehler beseitigt wurden ([BOB73],S.0.8); solche Fehler wurden im Compiler und LAP (wo es immer seltenbenutzte Sonderfälle gibt, die sich als fehlerhaft herausstellen) und selbst im Garbage Collector gefunden. Und das in einem oft verwendeten Programm nach Jahren Laufzeit!

In der darauf folgenden Zeit hat sich auch BBN-LISP verändert. 1972 gingen {\sc Teitelman} und D.Bobrow zum XEROX Palo Alto Research Center, wointensive Forschungen für die Büroautomatisierung auf der Grundlage der Verarbeitung natürlicher Sprache begannen. Da das LISP-System nun von zwei Institutionen gepflegt wurde, wechselte man 1973 den Namen zu InterLISP [TE74].

1973 schlugen D.Bobrow und Wegbreit eine Implementationstechnik fürdie Arbeit mit beliebigen Variablenumgebungen vor [BOB73c,d]. Damit sollteeinerseits das in der Kellerspeicherbindung von InterLISP nur teilweise korrekt behandelte Problem globaler Variablen gelöst werden ({\tt FUNARG}-Problem), andererseits hatten die Forschungen auf dem Gebiet der Künstlichen Intelligenz dazu geführt, da\ssman auswechselbareBindungsumgebungen (sogenannte ``Welten'') als wesentliche programmtechnische Instrumente ansah (s. S. 149ff.).

BBN-LISP und als Nachfolger InterLISP besitzen ja, wie auch LISP1.6 und MacLISP, keine Assoziationsliste wie LISP1.5. Ursache dieser Entscheidung war die Beobachtung, da\ssin einem virtuellen System die Assoziationslisterelativ oft (als Listenstruktur!) wenigstens teilweise auf dem externen Speichermedium ausgelagert ist. Der Kellerspeicher ist jedoch durch die häufige Arbeit, die mit ihm auszuführen ist, in seinen wichtigsten Teilen fast ständig resident. Eine Wertbeschaffung über die Atome, wie es in LISP1.6 üblich ist, erscheint aus dem gleichen Grund unerwünscht wie die über die A-Liste: Viele Seitenaustauschoperationen würden daraus resultieren.

Die Lösung, die schon für das pdp-1-LISP von 1965 erarbeitet wurde, besteht darin, da\ssin den Kellerspeicher Paare von Atom und Wert abgelagert werden.Damit wird gewissermaßen die A-Liste ``linearisiert''. Vorteile dieser Entscheidung sind, wie beabsichtigt, ein schnellerer Zugriff zu den Werten als über die A-Liste (wenn kein Seitenaustausch erforderlich ist, erweist sich das LISP1.6-Schema als überlegen), als auch eine größere Einfachheit, Variablenzugriff von compilierten Funktionen und Interpreter unter einen Hut zu bringen (deshalb der kompatible Compiler).

Die Kellerspeicherlösung ermöglicht in einfachen Fällen eine korrekte Arbeit mit globalen Variablen (upward FUNARG): Wenn das funktionale Argument in einemäußeren Bindungsbereich auftaucht und dort die Variablen global verwendet, hat man bei der Arbeit mit diesem fuktionalen Argument in inneren Variablenumgebungen nur die irrelevanten neuen Variablenbindungen zu überspringen.

Kompliziert wird jedoch die korrekte Versorgung mit Variablenumgebungen, wenn ein solches funktionales Argument als Wert in eine äußere Bindungsumgebung geliefert wird (downward FUNARG) oder wenn aus der Benutzung des funktionalen Arguments selbstwieder verschachtelte Umgebungen resultieren. Dann genügt die lineare Anordnung bzw. das Kellerspeicherprinzip nicht mehr; es mu\sseinelistenähnliche Struktur verwendet werden. Um in den linearen Zwischenstücken (wo keinerlei funktionale Argumente auftreten) geschlossene Kellerspeicherstücke mit der damit verbundenen günstigen Verarbeitungsgeschwindigkeit verwenden zu können, schlugen Bobrow undWegbreit den Spaghettistack vor.

Entsprechend den theoretisch erarbeiteten Modell wurde der Spaghettistack implementiert (von Hartley) und war etwa 1975 verfügbar. Inzwischen hattenWegbreit und Goodwin den Swapper für kompilierte Programmefertiggestellt (1974).

Die Pflege des InterLISP-Systems lag nach 1975 lange Zeit bei {\sc Teitelman, Hartley, Lewis} und L.M.Masinter. Teitelman war für die Hilfsmittel des Nutzers verantwortlich, d.h. er beaufsichtigte Prettyprinter, Editor, Break- und Trace-Programme, den Advisor, Printstructure und die Subsysteme DWIM, CLISP, Programmer's Assistant usw. 1977 berichtete er über eine Weiterentwicklung der Dialogunterstützung von InterLISP [TE77], die durch Menüs \footnote{ Menü ist ein Begriff aus der Digitalgraphik. Durch Angabe einer geordneten Menge von Operatoren (dem Menü) kann der Nutzer auf dem Bildschirm befindliche Objekte manipulieren, indem er auf die gewünschte Operation zeigt. Dadurch mu\sser nicht in Formulierungsmittel ausweichen, dieunbequem und schwer überschaubar sind.} und Fenster \footnote{ Fenster sindRegionen auf dem Bildschirm, die in gewisser Hinsicht als ein Objekt betrachtet werden. Sie können sich überlappen, dürfen verschoben werden usw., ohne da\sssich der Inhalt ändert.} dem Nutzer erlaubt, gleichzeitig mehrerekomplexe Programmumgebungen zu beherrschen und verschiedene Aufgaben zu verfolgen. Hartley war für die eigentlichen Systemprogramme verantwortlich,d.h. für Interpreter Garbage Collector, Compiler, Spaghettistack sowie alle von Hand kodierten Funktionen in Maschinensprache. Lewis' Aufgabenbereichumfaßte alle mit der Ein- und Ausgabe sowie der äußeren Umwelt (d.h. dem Betriebssystem zusammenhängenden Fragen. Masinter verwaltete denMustercompiler (pattern match compiler), das Programmpaket für Records (und nutzerdefinierten Datentypen) sowie MASTERSCOPE.

Ähnlich wie die MacLISP-Entwickler glaubten auch die InterLISP-Entwerfer an eine Zukunft des Systems auf Hardware-Niveau in einem microprogrammierten Rechner. Während BBN von einem pdp-11 ausging, versuchte man bei XEROX einen speziellen Kleinrechner zu entwerfen. Die Grundideen dafür hatte Deutschschon 1973 veröffentlicht [DEU73]. Zu welchem Resultat man dabei gelangt istkann für BBN aus einem Zwischenbericht von 1977 abgelesen werden [ASH77]. Über den Stand von XEROX wurde lange Zeit nicht viel bekannt, denn, so Fredkin: ``XEROX hat mehrGeheimnisse zu schützen als die gesamte US-Regierung'' [FRE77].Dann, 197? , erschien der Dolphin auf dem Markt... Dandelion, Star,...

Im Unterschied zu MacLISP sind seit 1972 in verschiedenen Teilen der Welt weitere InterLISP-Implementationen entstanden. Bekannt sind solche für die IBM/360, die Siemens 4004, die ICL-4, CDC3300, Burroughs 6700 und Fujitso M160 und M190 \footnote{Wie man hörte, lief ab 197? in Palo Alto keine pdp-10. Vielmehr mußten die LISP und TENEX-Fans einen Emulator auf dem verfügbaren Rechner herstellen (vgl. [TE77}).]. Begonnen hat diese Übertragung mit derInitiative der Arbeitsgruppe für Künstliche Intelligenz unter Sandevallin Uppsala. Hier hatte Jaak Urmi im Jahre 1970 eine kleinere experimentelleVersion des BBN-LISP für den Prozeßrechner Siemens 305 entworfen und einige Erfahrungen gesammelt. Als die Universität sich 1971 entschloß, eine IBM/360 anzuschaffen, wurden auch Kontakte zu BBN aufgenommen, um InterLISP zu übernehmen. Dies gelang in befriedigender Weise. So begannen denn im Frühsommer 1972 Urmi, B.Jansson und M.Anderson mit der Programmierarbeit. Dawesentlichen Teilen von InterLISP in LISP geschrieben sind, war die Hauptaufgabe dabei die Verwirklichung des Seitenverwaltungssystems.

Nach etwas mehr als einem Jahr lief eine experimentelle Variante (Urmi.schätzt 3 bis 5 Mann-Jahre) im OS/MVT. Als das System einigermaßen stabil war, kamen Wünsche für die Weitervergabe. So wurde 1975--76 in Zürich auf einer IBM/370 unter dem Betriebssytem CMS InterLISP aus Uppsala übernommen.

Etwa zur gleichen Zeit kamen Anfragen aus Großbritannien und Westdeutschland zur Übernahme von InterLISP auf die IBM-kompatiblem Rechner Siemens 4004 und ICL-4. In beiden Fällen glaubte man, da\ssdie Arbeit nur wenige Wochen dauernwürde, es zeigte sich aber, da\sskleine Unverträglichkeiten in denBetriebssystemen unangenehme Probleme mit sich brachten.

Die Transportation auf den Siemens 4004 wurde, unter Mithilfe Urmis,innerhalb einiger Monate bewältigt. Ab Ende 1977 verwaltete das Forschungslabor von Siemens dieses System selbstständig. Die ICL-4 Übernahme soll Ende 1977 in Edinburgh ebenfalls abgeschlossen worden sein.

Von Uppsala aus wurde InterLISP nach Japan übergeführt. Zunächst benutzte man als Zielanlagen eine IBM/370.158 bzw. 138. Später wurden die japanischen Rechner Fujitso M160 bzw. M190 verwendet (Februar 1978).

Von den übrigen InterLISP-Implementationen ist wenig bekannt. Die B6700-Übernahme in Los Angeles schein nicht beendet worden zu sein.

 

STANFORD LISP 1.6

Als 1967 die erste Version des LISP1.6 am MIT einigermaße stabil war, führte man das Programm nach Stanford über, wo inzwischen ebenfalls eine pdp-6 arbeitete. Dieses System wurde nun den speziellen Erfordernissen (insbesondere dem lokalen Time-Sharing-System) angepaßt). Allenund L.Quam überarbeiteten das System und verbesserten dabei u.a. dieEinleseprozedur, indem diese durch einen schnellen (superfast) tabellengesteuerten Scanner gesteuert wurde, der außerdem noch von den Nutzern einfach modifiziert werden konnte [QA72a]. Die wesentliche Arbeit leistehier Quam, während Allen ein neues Speicherbereichstellungssystemaufbaute, das den dynamischen Wechsel der Speicherbereichsgrößen ermöglicht. Außerdem entwicklte er den Editor ALVINE.

Diffie, der seit etwa 1970 ebenfalls dieses System pflegte, verbesserteauf Grund seiner Erfahrungen vom ... mit dem Compiler ([QA72a],App.F). Allerdings ``scheint der LISP1.6-Compiler keine so vollständige Überprüfung und Fehlersuche erlebt zu haben wie der MACLSIP-Compiler, denn seine Empfehlung ist unzuverlässigkeit'' ([WHI77], S.7) über Fehler selbst imGarbage Collection berichteten auch die Entwickler des UCI-LISP, die STANFORD LISP1.6 als Basis verwendeten.

Früher als in anderen LISP-Systemen hat man jedoch in Stanford die Notwendigkeit erkannt, die Beziehung zwischen physischen und logischen Eingabegeräten wesentlich lockerer zu gestalten, als das bis dahin üblich war.

Die normale Situation in einem LISP-System war, da\ssder Nutzer über zweiHauptein- und Ausgabeeinheiten verfügte: die Eingabe -- meist Kartenleser oder Fernschreiber -- und die Ausgabe -- meist Drucker oder Fernschreiber. Aus technischen Gründen waren weitere Ein- und Ausgabeeinheiten zugeordnet, die sich aber dem wirklichen Zugriff des Nutzers entzogen (für Systemabzüge usw.). Später wurden Geräte mit Bibliotheken hinzugefügt,von denen solch eine Bibliothek packenweise geladen wurde oder nur die gewünschte Funktion.

LISP1.6 machte dann 1967 den ersten Schritt auf die freie Auswechselbarkeit der externen Geräte. Für jedes Gerät gab es spezifische Kontrollzeichen, die das Gerät aktivierten. Speziell für DEC-Tapes (kleine, in Zweiachsen-Kasetten fest installierte Magnetbänder auf denen meist Zwischenergebnisse ausgelagert wurden) war eine Serie von Funktionen entwickelt worden, die das File-Directory ans LISP-System angeschlossen,von ihm ablösen und die Ein- bzw. Ausgabe steuerten. Das Display war völlig aus dem System der Geräte getrennt [PDP6c].

STANFORD LISP1.6 vereinheitlichte dieses Stückwerk zu einem Konzept logischer Files. Gleichgültig um welches Gerät, ob Teildatei oder ähnliches, es sich handelt, es kann mit der Funktion INPUT als ein neuer Eingabekanal deklariert werden, der dann mit INC alsaktuelle Eingabequelle erklärt bzw. wieder passiv gemacht wird. Ähnliches gilt für OUTPUT und OUTC bezüglich der Ausgabe. Der Nutzer stand damiteiner logisch unbegrenzten Vielfalt von Ein- und Ausgabemöglichkeiten gegenüber, aus der er während der Laufzeit seiner Programme dynamisch wählen kann (vgl. [Kur78]).

STANFORD LISP1.6 ist heute eines der am weitesten verbreiteten LISP-Systeme. Überall, wo mit pdp-10-Anlagen mit LISP gearbeitet wird (mit den wenigen Ausnahmen, da\ssInterLISP oder MacLISP verfügbar ist), hat man dieses System.Es wird auch über die Nutzergemeinschaft DECUS vertrieben.

Über die Weiterentwicklung zum UCI-LISP ist im Abschnitt über InterLISP gesprochen worden. 1977--78 wurde dieses System erneut an der Rutgers University weiter entwickelt.

Um 1980 aber wurde LISP1.6 in Stanford selbst kaum mehr benutzt. Es ist aber mit der pdp-10 exportiert worden. R.P.Gabriel hatte 198? MacLISP nachStanford gebracht und in das lokale Betriebssystem WAITS integriert.

 

Weitere LISP-Implementationen in den USA

Anfang 1967 erfuhr man an der Stanford University von der Arbeit Jan Kentsin Waterloo. Da man zu dieser Zeit gerade eine IBM/360.91 aufstellte, war man sehr interessiert, ebenfalls wie Waterloo ein einsatzfähiges LISP-System für diese Anlage zu haben. Kent kam nach Stanford und brachte die fertigenProgrammteile mit\footnote{Es gibt Informationen, da\ssdas ``Mitbringen'' derProgramme von Waterloo nach Stanford nicht ganz problemlos verlaufen sein soll...} Gemeinsam mit R. I. Berns hat er im Laufe des Jahres das Systemvervollständigt und zum Abschlu\ssgebracht. Es enthielt nun neben demInterpreter -- der dem von Waterloo weitgehend entsprach -- auch einen Compiler (von IBM übernommen).

Als Kent Stanford am Ende des Jahres verließ, wurde dieses LISP-System, nunallgemein STANFORD LISP/360 genannt, als relativ leistungsfähiges und schnelles System angesehen. Es sollte die Verarbeitung vor allem außerordentlich großer Programme ermöglichen.

Hatten im ersten Jahr neben Kent und Berns auch {\sc Hearn, F.W.Blair} und J.H.Griesmer\footnote{letztere eher indirekt, da sie in YorktownHeights an einem ähnlichen System arbeiteten} an der Implementation mitgearbeitet, so ist seit 1968 nur noch Berns für die Weiterentwicklung in Stanford zuständiggewesen. Blair und Griesmer hatten schon vorher (in Yorktown Heights)eine lokale Implementation entwickelt und haben auch später bei IBM mit LISP weitergearbeitet [BLA78b], und Hearn hat später in Salt Lake City dieWeiterentwicklung des STANFORD LISP/360 für die Verwendung als Basissystem seines Formelmanipulationssystems REDUCE [HEA73] eingeleitet.

Kennzeichnend für STANFORD LISP/360 ist, da\ssdieses System nicht auf dendamals verfügbaren Erfahrungen vom MIT bzw. von BBN aufbaute, sondern nahezu vollständig mit LISP1.5 kompatibel war. Beim Studium der Programme wird ersichtlich, da\ssder Code weitgehend der Beschreibung der LISP-Interpretationaus dem LISP1.5-Manual [MCC62c] mit der LISP-M-Sprache, die ja nur``pädagogisch'' gemeint war, entspricht. So werden z.B. bei der Abfrage des Funktionstyps für jede der Möglichkeiten extra Aufrufe des Unterprogramms GET (das die zugehörige Bedeutung beschafft) ausgelöst, statt die P-Liste mit einem Mal durchzuarbeiten.

Insgesamt erscheint die Arbeit des Interpreters schlecht gelöst, während für die Listenverarbeitung viele ausgezeichnete Detaillösungen gefunden wurden. Unter ihnen ist die gesamte Kellerspeicherarbeit zu nennen (die effizient ist) und die Implementierung der Basisfunktionen CONS, die ohneVergleiche bezüglich des Endes der Freispeicherliste auskommt. Statt dessen wird eine Unterbrechung ausgelöst und das Garbage Collection angesprungen -- auch dies in seiner Kompaktheit und Kürze ein hervorragendes Beispiel für die harmonische Gestaltung der Grundentscheidungen im System.

Aus heutiger Sicht sind allerdings manche von ihnen in Frage zu stellen: Zeiger sollten, auf jeden Fall in der IBM/360, ihren Typ mit enthalten und nicht erst das Objekt, auf die gezeigt wird; das Garbage Collection macht vom Kellerspeicher unnötig oft Gebrauch [KUR76b]. Dennoch soll hier auf eineeingehende Kritik verzichtet werden.

Seit 1967 ist STANFORD LISP/360 nicht mehr ernstlich revidiert worden, sondern nur durch Neuaufnahme von Funktionen und Erweiterung gegebener Möglichkeiten gewachsen. Berns hat in Stanford neben der Systempflege[LISP] auf die Einbettung in das Stanforder Time-Sharing-System aufIBM/360.67 vorgenommen [BERN71].

In Utah, wie übrigens auch in der überwiegenden Zahl der Installierungen außerhalb der USA, wurde das System vornehmlich für die Unterstützung von REDUCE gebraucht. Für diese Zwecke erfüllte dasLISP-System nicht alle Wünsche. Um z.B. Schwierigkeiten mit Speicherabzügen und der Verteilung der Speicherbereiche zu beheben, wurde eine Menge Arbeit geleistet [KAY75]. Die wesentliche Neuerung aus Salt Lake City sind aber dieganzen Zahlen beliebiger Größe, die in das System der einfachen Datentypen eingegliedert wurden. Die Programme dazu wurden nahezu ohne Änderung aus dem STANFORD LISP1.6 übernommen (wo sie wiederum in Anlehnung an Collin'sFormelmanipulationssystem SAC [COL71] programmiert sind). Weitere kleinereVerbesserungen und die Einbringung des STANFORD LISP/360 in das Time Sharing System CP/CMS sind in Frankreich durch A.Lux and der UniversitätGrenoble [LUX77] durchgeführt worden.

STANFORD LISP/360 dürfte um 1980 das meistbenutzte LISP-System der Welt gewesen sein. Das liegt einerseits daran, da\ssdieses System praktisch das einzige fürIBM/360-Anlagen gewesen ist, das vertrieben wurde, und andererseits da\ssdie fast kostenlose Verteilung in Verbindung mit REDUCE auch viel zurPopularität beigetragen hat.

Im Zusammenhang mit REDUCE gibt es einen weiteren Aspekt, der für dieLISP-Geschichte nicht ohne Auswirkung geblieben ist: Hearn hatte 1964[HEA64] begonnen, mit LISP-Programmen für die Formelmanipulation Probleme derPhysik zu bearbeiten. Die Erfolgen ermutigten ihn, systematisch auf dem Gebiet der Symbolverarbeitung vorzugehen. Er begann das System REDUCE imLISP1.5 System auf der IBM/7090 der Stanford University aufzubauen. Bald kamen erste Interessenten (Hearn selbst ist ja Physiker), und das Systemkonnte wegen der Verträglichkeit der LISP-Implementationen sowohl auf verschiedenen IBM/7090-Installationen als auch auf dem Q-32 der System Development Corporation benutzt werden. Er selbst hat die frühere Version seines Systems zwischen 1964 und 1965 nach England und Westdeutschland gebracht. Kurz nach dem 1967 das erste Manual geschrieben war [HEA67], änderte sichjedoch die Situation: In Stanford wurde die pdp-6 aufgestellt, und LISP1.6 war verfügbar. Dieses System unterschied sich in einigen wichtigen Eigenschaften sehr von LISP1.5. Die Situation blieb bestehen, als mit STANFORD LISP/360 ein weiteres, bis in die Einzelheiten korrektes LISP1.5 verwendbar wurde.

Hearn schlug den Weg ein, mit einem Präprozessor in den verschiedenenBasissystemen zu einer Vereinheitlichung der Ausgangssituation für REDUCEzu gelangen und das eigentliche REDUCE über diesem Grundsystem aufzubauen.So wurde es möglich, da\ssein und dasselbe LISP-Programmsystem auf zwei rechtverschiedenen Rechnern und verschiedenen LISP-Versionen benutzbar wurde [HEA67].

Die Auseinandersetzung mit den zu dieser Zeit neu entstandenen LISP-Systemen bei BBN (BBN-SDS940-LISP) und an der University of Texas in Austin (UT-LISP) führte zu der Idee, mit Hilfe eines Präprozessors alle diese Systeme kompatibel zu machen, d.h. also eine standardisierte LISP-Umgebung zu schaffen. Hearn formulierte seine Ideen Anfang 1969 [HEA69]. Die Grundlagevon STANDARD LISP, wie er diese einheitliche Basis nannte, sollte LISP1.5 sein. Von den 139 Grundfunktionen in LISP1.5 [MCC62c] sollten 67 völligungeändert bleiben. Dies waren vornehmlich Funktionen zur Listenmanipulation, Funktionale, das PROG-Feature sowie die Mehrzahl der arithmetischen und derP-Listenfunktionen. Acht Funktionen, unter ihnen etwa ERRORSET und SETQ,wurde eine etwas andere Bedeutung zugeordnet (SETQ sollte auch für freieVariable verwendbar sein anstelle von CSETQ). In sechs Sachbereichen trugSTANDARD LISP den seit 1962 vorangegangenen Entwicklungen Rechnung und ging über LISP1.5 hinaus:

  1. Bei der Behandlung freier Variabler und von Konstanten.Auf diesem Gebiet bestanden 1968--69 wesentliche Unterschiede zwischen den verschiedenen LISP-Versionen. Da STANDARD LISP, nach der Meinung Hearns,nicht die moderneren Lösungen von LISP1.6 oder BBN LISP aufgreifen konnte, mußte man sich Beschränkungen auferlegen. Drei Fälle waren nach HearnsMeinung behandelbar: Die Konstanten, die am Anfang samt Wert zu deklarieren wären und dann durch die jeweiligen Werte ersetzt werden konnten. Die globalen Variablen, die in keiner Variablenliste irgendeines LAMBDA oder PROG auftauchen. Hierbei kann keinKonflikt zwischen A-Listen-Implementation und Kellerspeicherimplementation auftreten -- eine SPECIAL-Deklaration ist möglich, die eine Wertzelleeinrichtet. Für die interpretative Auswertung mu\ssmit extra Zugriffs- bzw.Speicherfunktionen gearbeitet werden (GTS, PTS von GET SPECIAL, PUT SPECIAL).

    Schließlich mußten die Variablen betrachtet werden, die an irgendeiner Stelle gebunden werden und an anderen Stellen frei sind; Hearn nannte sie extended variables. Falls solche Variablen verwendet werden, so die Lösung in STANDARD LISP, mu\ssdie Gesamtheit der betroffenen Funktionen entwedercompiliert sein oder für die Interpretation bereitstehen.

     

  2. Funktionale Argumente. Um zwischen den funktionalen Argumenten zuunterscheiden, die Bezug nehmen auf die Umgebung zur Bindungszeit, und denjenigen, die das nicht tun, wurde die Lösung von LISP1.6 übernommen. Demgemä\sswerden die einfacheren Fälle mit FUNCTION behandelt, d.h.praktisch gequotet, während die anderen mit $\ast$FUNCTION zu kennzeichnensind. Dabei sind die vorkommenden freien Variablen natürlich zu deklarieren.
  3. Zeichenbehandlung. Beim zeichenweisen Einlesen bzw. beim Zerlegen einesAtomnamens in seine Bestandteile (via EXPLODE) entstehen Atome mit einemNamen aus nur einem Zeichen. STANDARD LISP schlug hier eine spezielle Unterscheidung vor zwischen Zeichenatomen und gewöhnlichen (literalen) Atomen vor. Zeichenatome haben keine P-Listen und stehen in keiner Beziehung zum Atom mit demselben Namen. Sechs Funktionen zur Arbeit mit diesen Zeichenatomen wurden vorgeschlagen (READCH, PRINC, EXPLODE, COMPRESS, LITER und DIGIT),daneben noch einige zur Steuerung der Ausgabe (PRIN, OTLL, POS, SPACES).Diese hätten wohl besser in die nächste Gruppe gehört.

     

  4. Filemanagement. Gegenüber LISP1.5 mußte STANFORD LISP den Wechsel derQuelle des Eingabestroms und des Ziels für den Ausgabestrom ermöglichen. An andere Möglichkeiten zur Arbeit mit externen Dateien wurde nicht gedacht. Die vorgeschlagenen Funktionen (OPEN, WRS, RDS, CLOSE) erlaubten Deklaration,Wechsel zur neuen Datei und Abschließen.

     

  5. Funktions- und Makrodefinition. Merkwürdigerweise blieb STANDARD LISPauf diesem Teilgebiet etwas unentschlossen, obwohl doch einige neue Ideen schon 1969 vorlagen. Beeindruckt von der durchgehenden Compilierung des Q-32-LISP sollte Definition und Compilierung prinzipiell zusammenfallen. Mit DEFINE (parallel dazu DEFEXPR) sollten EXPR definiert werden. FürMacros war die Funktion MACRO vorgesehen; ansonsten folgte man den Ideen Harts [HART63b], vermittelt durch C.Weissman [WEI67].Außerdem sollte mittels GETD jede Funktionsdefinition erreichbarsein.

     

  6. Felder. Die Entwicklung auf diesem Teilgebiet war zu dieser Zeit davongekennzeichnet, da\ssman Feldtypen eingeführt hatte, deren Elemente (ausEffizienzgründen) nicht gültige LISP-Objekte sein konnten. STANDARD LISP schlug die strenge Begrenzung der Funktionen SETEL und GETEL fürEinspeichern bzw. Zugriff von Feldelementen vor.

Daneben steht eine gemischte Folge von Einschränkungen gegenüber LISP1.5, die durch den Zwang, den größten gemeinsamen Nenner aller aktuell existierenden LISP-Systeme zu finden, bestimmt sind. Atomsymbole mit 24 Zeichen, nur fünf Argumente für Funktionen, Verzicht auf LABEL, Verarbeitung mit EVALQUOTEusw. usw. sind charakteristische Beispiele dieser Einschränkungen.

So verdienstvoll der Ansatz zu STANDARD LISP auch war, denn ein Erfolg von Standardisierungsbemühungen für LISP hätte die weitere Sprachentwicklung wesentlich beeinflussen können, durch die wenig tragfähige Mischung neuer Ideen und eingeschränkter Parameter von zeitgenössischen LISP-Implementationen konnte nicht viel mehr erreicht werden, als einen privaten Sprachstandard zu begründen. Außerdem sah die LISP-Gemeinschaft leider die Notwendigkeit einer Standardisierung noch nicht ein.

Dennoch sind durch die Entwicklung von Präprozessoren für STANFORD LISP1.6, STANFORD LISP/360 und CDC6000 LISP1.5 (UT-LISP) immerhin Voraussetzungen für eine recht große Maschinenunabhängigkeit des Formelmanipulationssystems REDUCE geschaffen worden. Ein wesentlicher Nachteil (welcher?) desPräprozessor-Ansatzes wurde deutlich, als RLISP, die ALGOL-ähnlicheFormulierungssprache für REDUCE, als mit MLISP oder CGOL gleichwertigeLISP-Erweiterung verstanden wurde und man versuchte, Programme zu schreiben, die STANDARD LISP-Programme verarbeiten sollten.

Das STANDARD LISP-Modell ging davon aus, da\ssauf dem gegebenen Rechner ein``Gastgebersystem'' existiert, das durch den Präprozessor mit STANDARD LISP überlagert wurde. Damit wurden auf verschiedenen Maschinen (bzw. in verschiedenen LISP-Systemen) gleiche STANDARD LISP-Funktionen verschieden realisiert. Für einen maschinenunabhängigen Compiler, der nach den Vorstellungen von Hearn in RLISP für STANDARD LISP geschrieben werdenmüßte, wäre damit die Aufgabe kompliziert durch systemabhängige Quellprogramme. Die Schlußfolgerung aus dieser Situation war für Hearn undseine Mitarbeiter, STANDARD LISP müsse eine präzise Sprachbeschreibung bekommen, in der die Datenstrukturen und die Arbeitsweise der Grundfunktionen genau festgelegt sind [MAR77].

Der neue Report für STANDARD LISP enthielt diese Spezifikationen. Die Absicht war dabei, da\ssein vorgefundenes LISP-System nun entsprechend zu ändern ist, wenn es den Standard erfüllen soll. Der Report selbst sollte nur der erste Schritt sein. Die Autoren beabsichtigten, ähnlich wie J.S.Moore dies für InterLISP getanhatte [MOO76], auch eine definierende Beschreibung auf dem Niveau derImplementierung vorzulegen.

Niemand erwartete 1977, da\ssmit diesem Report wirklichein Sprachstandard eingeführt werden konnte, der etwa der Standardisierung von FORTRAN [FOR66] oder COBOL [COB74] entspricht. Die Entwicklung dermaßgebenden LISP-Systeme war so weit fortgeschritten, da\sseineStandardisierung von LISP chancenlos schien. Es wäre schon viel erreicht gewesen, wenn die verschiedenen Implementationen dieser Systeme einigermaßen verträglich waren. 1969 war die Situation noch günstiger.

Wenn aber im Kreis der Interessenten der Formelmanipulation neben MacLISP und InterLISP nur STANDARD LISP verwendet worden wäre, wäre dies ein erstaunlicher Erfolg gewesen. Dazu ist es nicht gekommen. STANDARD LISP blieb ein Dialekt unter mehreren, die von Freunden erarbeitet wurde und von diesen an verschiedenen Maschinen implementiert werden wird. Bekannt geworden sind Implementationen auf der IBM/360-/370, pdp-10 (DEC-10, DEC-20), B6700, B1726 und UNIVAC1108.

Die Datentypen in STANDARD LISP entsprechen dem gewöhnlich implementierten Spektrum. Die Namen der Atomsymbole sind wiederum auf 24 Zeichen beschränkt -- eine schwer verständliche Entscheidung.

Die Funktionstypen werden mit der von InterLISP begründeten Terminologie beschrieben: Unabhängig voneinander gibt es die Merkmale EVAL oder NOEVALfür die Funktionen, die ihre Argumente ausgewertet bekommen bzw. unausgewertet, und SPREAD oder NOSPREAD für die Funktionen, denen dieArgumente auf Parameter verteilt werden bzw. als Liste einem Parameter zugeordnet sind.

Die beschriebenen Funktionen -- es sind etwa 115 -- machen die übliche Grundmenge aus. Es fällt auf, da\ssgewisse konventionelle Ideen von LISP1.5übernommen worden waren. Ein Beispiel dafür sind die sogenannten Flags in denP-Listen, deren Beziehungen zu den gewöhnlichen Eigenschaften recht vage beschrieben sind. Dies rührt daher, da\ssin LISP1.6 Flags keine besondereRolle mehr spielten und regelrechte Eigenschaften mit den Werten NIL und Tsind, in STANFORD LISP/360 dagegen Indikatoren ohne Eigenschaft. Zur Funktionsdefinition wurden Sandewalls Funktionen DE, DF und DMakzeptiert. Zu den Ein- und Ausgabefunktionen werden diesmal rigoros alle Funktionen zur Zeichenmanipulation geschlagen. Dies hat für COMPRESS undEXPLODE noch einen präzisen Sinn, da man sich als Quelle bzw. Ziel dieZeichenliste vorstellen kann (s. S.62).

Viele Gedanken hat man sich um die Variablentypen gemacht. Um die 1969 als Extended Variables bezeichneten globalen Variablen abzuheben, wurde derVariablentyp der Fluid Variables eingeführt. Diese sind irgendwo gebundenund werden in den Unterfunktionen global verwendet. Tritt eine neue Bindung auf, so mu\ssdie alte gerettet werden. Nur die jeweils aktive ist erreichbar.Die Kooperation von interpretierten und compilierten Funktionen wird als gesichert angenommen.

Die Arbeit an dem transportablen LISP-Compiler, die bei dem alten STANFORD LISP/360 Compiler begann und durch mehrere Zwischenstufen gelaufen ist (dabei wurden zunächst vorgesehene Optimierungen des Quellcodes wieder beseitigt) war bis 1983 abgeschlossen[HEA83].

STANFORD LISP/360 blieb nicht das einzige LISP-System für IBM/360 bzw. /370 Rechner. Die vielen Maschinen, die von Universitäten und Forschungsinstituten angeschafft worden waren, wurde teilweise auch mit verschiedenen Betriebssytemen gefahren. In dem ersten LISP-Bulletin, das im April 1969 in den SIGPLAN-Notices [BO69] erschien, werden allein drei LISP-Systeme fürdiese Anlagen erwähnt\footnote {Kurioserweise (eine der vielen Unzuverlässigkeiten in der auswertbaren Literatur) wird das LISP/360 weder für Waterloo noch für Stanford erwähnt.}. Eines war Anfang 1968 bei SDC in Santa Monica als Nachfolger des Q-32-LISP für das Betriebbssystem ADEPT [LI69] auf einer IBM/360.50 implementiert worden [BAR68], eines an demRensselaer Polytechnic Institute in Troy (NY.) und schließlich eines für die IBM/360.91 am IBM-Forschungsinstitut in Yorktown Heights, das unter verschiedenen Betriebssytemen lief: im OS, im OS mit TSS und im System CP/CMS.

Bei IBM war das Anbieten der verschiedenen LISP-Systeme, die dort implementiert worden waren, lange Zeit als entweder geschäftlich uninteressant oder zu große Mühen verursachend vermieden worden. So ist wenig über die Arbeit bekannt, die über Jahre hinweg hauptsächlich von Blair und Griesmer geleistet wurde.

Nach Blairs Angaben konnte man in Yorktown Heights schon 1961 einLISP1.5-System vom MIT benutzen. Damit sind wohl Probleme der Formelmanipulation und andere nichtnumerischen Aufgaben gelöst worden. Allerdings war der Nutzerkreis alle Jahre sehr beschränkt. Zwischen 1965 und 1966 scheint man, wie E.G.Wagner berichtet [WAG78], Zugriff zu demLISP-System auf der IBM M44 gehabt zu haben. Es ist nicht klar, ob dies das von D.Wooldrige erstellte System mit dem Hash-CONS war [BOB68b][S.152] oder ein anderes, das von Edwards, vielleicht unter Mithilfevon Abrahams aufgebaut wurde [BLA71]. Kurz darauf waren Blairund Griesmer an der Implementation von LISP2 auf der IBM/360 beteiligt.Da dieses Projekt zusammenbrach, begannen sie mit einer eigenen Implementierung für diesen Rechner.

Kennzeichnend für dieses IBM-System ist die Orientierung auf Halbworte. Dadurch sparte man Platz, verfügte aber andererseits nur über einen kleinen Adreßraum. Damit dieser ausreichte, wurden möglichst nur Listenstrukturen in diesem Bereich angesiedelt. Die Atome wurden, ähnlich wie im pdp-1-LISP von BBN, in Teile zerlegt, von denen nur ein Teil im Zeigerbereich lag. Von diesem Teil aus gingen die Zeiger zur Buckettliste der Objektliste und auf die p-Liste.

Das System enthielt ganze und Gleitkommazahlen, Zeichenketten und Vektoren. Es bot ein recht großes Spektrum an Funktionen. Der Compiler war schon Mitte 1967 so weit entwickelt, da\ssKent ihn nach einem Besuch in YorktownHeights in das STANFORD LISP/360 übernehmen konnte.

Da Maurer [MAU73] von einem LISP1.4 berichtet, in dem seine Beispiele unterMithilfe von Griesmer abgearbeitet wurden und in dem größeren Bericht dieVersion LISP1.15 erwähnt wird, ist es nicht unwahrscheinlich, da\ssdie von {\sc J.Sammet} [SAM69] ohne Referenz angegebenen Systeme LISP1.17 bzw. LISP1.19IBM-Produkte waren.

Das jeweilige System galt als ``experimentelles System'', das zur Benutzung einem kleinen Kreis von nicht viel mehr als fünf Programmierern zur Verfügung stand.

Etwa 1970 wurde dieses System für den Aufbau des Formelmanipulationssystem SCRATCHPAD [GRI71b] verwendet; die dabei angewandte Technologie wurdeverallgemeinert, und eine Beschreibungssprache für Metasysteme [JE70] wurdeentwickelt. Im Betriebssystem CP/CMS konnte man die Metasprache LPL[BLA70a] benutzen. Ihr Niveau entsprach etwa MLISP. Da dieSyntaxverarbeitung auf den Idee von V.Pratt bezüglichOperator-Precedence-Grammars basierte, konnte das System Präfixoperatoren außerordentlich günstig verarbeiten. Für den Nutzer resultierte etwa, daß

\begin{center}A B C \hspace{1cm} in \hspace{1cm} (A(B(C)))\end{center}

übersetzt wurde. Das ``-Zeichen wurde zur Umschaltung in reine LISP-Syntaxverwendet, Vektor-Datenobjekte mit spitzen Klammern. Wie schon MLISPenthielt LPL ebenfalls ALGOL-ähnliche Zyklenkonstruktionen.

Etwa 1974 überlegten die Mitarbeiter von IBM, ob sie einen neuen Anlauf wagen sollten. Man begann mit der ``Task Force''. Die Entscheidungen fielen, und 1975 wurde eine völlig neue Implementation gestartet. Diese sollte sich nun auf Doppeltwortzellen orientieren, um den gesamten Adreßraum verfügbar zu haben.

Im Laufe des Jahres 1976 ist dann die wesentliche Arbeit an dem neuen System LISP/370 geleistet worden. Daran hatte auch White vom MIT einen Anteil.

Typisch für LISP/370 sind die als Zeigerkomplexe organisierten Datenstrukturen, und die, insbesondere bei der Ein- und Ausgabe, recht einmaligen Funktionen.

1977 konnte das System LISP/370 den Nutzern angekündigt und angeboten werden, 1978 kam es als Installed User Program Nr. 5796-PKL auf den Markt [IBM78].

Ein weiteres LISP-System für Maschinen des Typs IBM/360 wurde Anfang der siebziger Jahre an der University of Michigan in Ann Arbor von {\sc Bruce Wilcox} und anderen erstellt [HAF74]. Dieses System lief im Michigan TerminalSystem und ist in enger Anlehnung an MacLISP gestaltet worden. Deshalb hie\sses zunächst MacLISP/360. Eine verbesserte Version mit dem Namen MTS-LISP entstand etwa 1974. Da es unentgeltlich verteilt wurde, ist eine auswärtige Verwendung anzunehmen [GOE76]. So ist es unter anderem an das Institut fürdeutsche Sprache in Mannheim gelangt.

In dem ersten Artikel zu STANDARD LISP [HEA69] hatte Hearn die an derUniversity of Texas in Austin durchgeführte LISP-Implementation erwähnt. Die Geschichte dieses Systems ist typisch für die LISP-Verbreitung.

In einem Kursus hatten W.W.Bledsoe und S.Papert (vom MIT) in Austindie Idee und Resultate der jungen Wissenschaftsdiziplin von der Künstlichen Intelligenz bekanntgemacht und begeisterte Studenten zur Mitarbeit bzw. zur Mithilfe bei Forschungen auf diesem Gebiet gewonnen. Dies war im Herbst 1966. Die Programmierung sollte natürlich in LISP vorgenommen werden, es war aber kein Rechner verfügbar, für den irgendwo eine LISP-Version implementiert war. Bledsoe bestärkte die Studenten, selbst mit der LISP-Implementierungfür den Universitätsrechner, eine CDC6600, zu beginnen [MOR76].

Man initiierte ein Graduate Student Project, das noch im Herbst von den Studenten J.B.Morris, R.Richardson und D.C.Singleton gestartetwurde. Später kam noch ein Undergraduate Student, R.Fredrickson, hinzu.Gemeinsam entwarfen und programmierten sie ein LISP1.5-System. Dieses Programm soll etwa gegen Ende des Frühjahrssemesters im Jahre 1967 einsatzbereit gewesen sein.

Die Entwurfsarbeit war durchaus nicht einfach, denn die Maschinenstruktur der CDC6600 ist recht verschieden von anderen Maschinen. Für LISP eher ungünstig ist die enorme Wortlänge von 60 Bits, der 18 Bit-Adressen gegenüber stehen. Die Studenten entschieden sich, jeweils 6 Bits pro Wort als Typanzeiger zu verwenden. Damit waren in den Listenstrukturen 12 Bits unbenutzt! Dies ist eine mutige Entscheidung, wenn man bedenkt, da\ssohne weiteres Variantendenkbar waren (etwa in der Atomstruktur), wo man sich zur besseren Speicherausnutzung von LISP hätte entfernen können. Bei den P-Listen lag die Verwendung des dritten Adreßteils allerdings nahe: Man bekommt ja Indikator, Eigenschaft und Listenzeiger in ein Wort. Auch für Namenszellen, Zahlen u. dgl. lassen sich die vielen Bits gut einsetzen.

Das CDC6600-LISP wurde offenbar sofort nach außerhalb vergeben, denn das Bedürfnis nach ihm bestand schon lange. Wie üblich, gab es noch eine Reihe Fehler; Morris und Singleton verbesserten diese und verwerteten dieersten Nutzererfahrungen [MOR68a]. Anfang 1968 wurde nach einer genauerenDurchsicht des Systems (LISP1.55) dieses sogar in die von der CDC6600-Nutzergemeinschaft betreute Software aufgenommen (CDC-VIM-6600 Users Group Software Library). 1969 hatten das System schon an die 20 Installationen übernommen. Unter anderem ist es auch in die VR Polen nach Warschau gelangt.

Morris hat das System bis 1969 gepflegt. Im Sommer 1969 übernahm nachihm {\sc E.M.Greenawalt} das CDC6600-LISP-System. Er überarbeitete das System vollständig, fügte einen Compiler hinzu und schrieb auch ein LAP-Assemblerprogramm. Besonders bemerkenswert ist dabei das neue Interpretationsschema für $\lambda$-Ausdrücke, das auf einer Variablenbindungstechnik beruht, die verschieden ist sowohl von der A-Listenimplementation in LISP1.5 als auch von dem LISP1.6-Schema, wo die Werte über eine Wertzelle erreichbar im Kellerspeicher angeordnet sind.

UT-LISP [GRE70], wie das System nun genannt wurde\footnote{von {\em Universityof Texas} at Austin}, verwendet dafür eine lokale Push-Down-Liste, d.h.einen Keller, der als Liste repräsentiert ist und direkt vom Atom aus erreichbar ist (im Car-Feld). Der aktuelle Wert befindet sich im Cdr-Feld. Damit sind die Wertzugriffe sicher sehr schnell ausführbar -- die Verwaltung durch dezentrale Push-Down-Listen aber scheint nicht sehr günstig zu sein.

UT-LISP war um 1980 (in der Version 4.0) eines der meistbenutzten und einsatzfähigsten Systeme [GRE75]. Mit ca. 220 Funktionen, guten interaktivenMöglichkeiten, freier Verfügbarkeit beliebiger Ein- und Ausgabefiles ist es recht leistungsfähig. Eine diese Eigenschaften verstärkende Möglichkeit besteht darin, da\ssder Nutzer zwischen verschiedenen Systemkonkretisierungwechseln kann. Dieser Dienst heißt in der UT-LISP-Terminologie Overlay.Wird mit einem leeren LISP-Speicher gestartet und eine Reihe von Funktionen eingelesen, so entsteht schlie\sslich eine Arbeitsumgebung, die durch die interne Verfügbarkeit eines Systems von Funktionen charakterisiert ist. In diesem konkreten Systemaufbau ist nun Programmierarbeit oder normale Problemrechnung möglich. Da eine solche Systemkonkretisierung erst durch eine lange Reihe von Eingabeoperationen erreichbar ist, liegt es nahe, sie insgesamt als Einheit zu betrachten und als ein Datenelement auf externe Speicher zu retten. Bei späteren Systemstarts ist nur noch eine Eingabeoperation nötigt, die des Overlays.

In dieser Hinsicht steht UT-LISP nicht allein -- auch STANFORD LISP/360, InterLISP und DOS/ES LISP1.6 erlaubten ähnliche Operationen, nur da\sshier in derbetriebssystemabhängigen Terminologie von Prüfpunkten (Checkpoints) gesprochen wird. Einzigartig sind die Möglichkeiten, die man in UT-LISP hat, um von einem Overlay zu einem anderen zu gelangen, dort gewisse Teilaufgaben erledigen und dann in das Ausgangssystem mit dem Ergebnis wieder eintreten. Diese Arbeitsweise kann sogar rekursiv organisiert sein [GRE73].

1973 verbrachte Greenawalt in Livermore beim Lawrence RadiationLaboratory und sorgte dort für die Überführung von UT-LISP in das Betriebssystem LTSS, das auf der CDC7600 läuft. Die Weiterentwicklung geriet dann ins Stocken, als Greenawalt 1974 Austin verließ. R.A.Amsler undJ.Slocum betreuten danach das System. Sie faßten alle von Greenawaltzuletzt gemachten Erweiterungen und neue Elemente zusammen [AMS75]. FürCDC-Rechner, die nicht mit dem in Austin verwendeten relativ seltenen Betriebssystem ausgestattet sind, mu\sseine Anpassungsarbeit durchgeführtwerden.

Weitere Verbesserungen am UT-LISP sind auch in Lausanne, am ISSCO-Institut unter P.Hayes und N.Goldman durchgeführt worden [GOLM75].

Für die Rechnerfamilie UNIVAC 1100 [IB78] wurde erst 1969 ein LISP-Systementwickelt. Über Umstände dieser Implementation ist nicht viel bekannt. UNIVAC LISP ist ein strenges LISP1.5 System, d.h. für die Variablenbindung wird eine Assoziationsliste verwendet. Als Begründung für diese Entscheidung gibt der Implementator, E.Norman, an, die SPECIAL-ZellenImplementation würde nicht funktionieren (``it just doesn't work'') und meint damit natürlich die Schwierigkeiten, ein korrektes FUNARG zubewerkstelligen. Sein Beispiel, die Kompositionsfunktion für zwei funktionale Argumente, ist sowohl einfach wie natürlich und würde tatsächlich in einer einfachen LISP1.6-Implementation (etwa DOS/ES LISP1.6) nicht korrekt ausgeführt.

\begin{center}(DE COMPOSE (F1 F2) (FUNCTION(LAMBDA(X) (F1(F2 X))))).\end{center}

Dies ist eines der einfachsten Beispiele für ein sog. downward FUNARG.

Im Zusammenhang mit den Atomsymbolen kann man erkennen, da\ssUNIVAC-LISP inseiner Rigidität so etwas wie ein Vorläufer für SCHEME gewesen ist. Die Atome waren als Aggregat von vier Listenzellen (2 Worten) aufgebaut und enthalten neben Wert, P-Liste und Namenzeiger noch den Zeiger für das Hashbucket (Liste gleicher hashcodes). Es gab also keine Funktionszelle! Atome waren nicht gleichzeitig als Variable und als Funktionen verwendbar. Es war gerade die Absicht des Entwerfers, dies unmöglich zu machen -- dabei hätte er sich auf McCarthy [MCC63e]berufen können. Funktionen werden in der Tat wie normale Objekte behandelt und auch mit den Funktionen CSET bzw. CSETQ zugewiesen.

UNIVAC LISP bot zunächst etwa 100 Grundfunktionen. Dabei sind die arithmetischen Funktionen recht stark vertreten, die Funktionen zur Listenverarbeitung entsprechen etwa dem normalen Spektrum, und Ein- und Ausgabefunktionen sind ebenfalls angemessen vertreten. In der Menge der Funktionale sind sehr unübliche Namensgebungen anzutreffen (MAPC heißtMAPCAR, MAPCAR heißt INTO). Die Auswirkungen der Behandlung derFunktionsdefinition als normaler Wert zeigen sich in der Funktionsmenge: Man kann keine FEXPRs definieren, wie überhaupt der Begriff verschiedenerFunktionstypen völlig aufgelöst ist. Die ``Spezialformen'' wie PROG, CONDusw. sind offenbar ``eingebaut'', neue sind nicht hinzufügbar. UNIVAC LISP kann damit als sehr moderner LISP-Dialekt gewürdigt werden. Erst viel später wurde die Abkehr von der Auffassung, da\ssSpezialformenFunktionen seien, von anderen Autoren aufgenommen. Wiederum kann auf SCHEME verwiesen werden.

In UNIVAC LISP ist der Speicher in Seiten aufgeteilt, in die typenrein die Daten abgespeichert werden. Es wird unterschieden zwischen Zahlen, Atomen (literalen Atome), compilierten Programmen, und einigen speziellen Typen außer den Listenzellen [NOR69b]. Die Seitenaufteilung hat den Vorteil, da\ssder Nutzer keine Aufteilung desSpeichers im voraus vornehmen muß. Die Seiten verschiedener Typen können willkürlich angeordnet sein. Durch das Garbage Collection werden dabei alle Typen erfaßt. Es wird allerdings nicht kompaktiert. Insgesamt scheint die Speicheraufteilung sehr gelungen (sie ähnelt ja den Schemata von InterLISP bzw. MacLISP (BIBOP)) und fähig für Erweiterungen (Software-Paging).

UNIVAC LISP ist unter anderem an die Universität von Maryland übernommen worden. Dort wurde an dem System weiter gearbeitet. Etwa 1973--74 hat {\sc R.L.Kirby} eine kompatible Version für die pdp-11 erstellt [KIR75]. Sieenthält nun auch Felder, leitet aber insgesamt unter den unharmonischen Festlegungen des Vorbildes.

Sehr verbreitet ist auch das pdp-11-LISP von der Harvard-University gewesen. Es wurde 1974--75 von F.Howard am HRSTS Science Center in Lynnfieldprogrammiert [HOW75]. Ebenfalls für die pdp-11 ist das System von B. Webb,das am Bell Telephone Laboratory aufgebaut wurde. Alle drei laufen in dem weithin benutzten Betriebssystem UNIX [RIC74].

 

LISP in Europa

 

Großbritannien

In Großbritannien begann die LISP-Rezeption außerhalb der USA.

Ein loser Kreis von Wissenschaftlern und Freunden Christopher Stracheystraf sich um 1960 bei ihm zum Tee und diskutierte neue Entwicklungen auf dem Gebiet der Computer Science. Als McCarthys Artikel in den Communications ofACM im März 1960 erschien, wurde man aufmerksam und beschäftigte sich damit. Irgendwann bald danach machte M.Woodger D.R.Jenkins vom Royal RadarEstablishment in Malvern, Worcester, den Vorschlag, diese interessante Sprache zu implementieren.

Jenkins hatte Interesse an der Sache, und es gab in seinem Institut gewisseErfahrungen bei der Sprachimplementierung: Man hatte eine einfache algebraische Sprache entwickelt und einen Compiler geschrieben. P.W.Woodward, der an dieser Angelegenheit mitgewirkt hatte, war bereit, Jenkinszu unterstützen. So begannen beide, auf Grund des Artikels ``Recursive functions...'' [MCC60c] LISP zu implementieren.

Am Royal Radar Establishment verfügte man damals über den TREAC, einen nicht allzugroßen Rechner, der mit einer Trommel ausgerüstet war. Es wurde ziemlich rasch klar, da\ssmit dem kleinen Hauptspeicher nicht viel anzufangen war.Durch die vielen Trommeltransfers wurde die LISP-Interpretation recht langsam. In einem Artikel über LISP [WOW61] berichten die Implementatoren leider sehrwenig über ihre Arbeit, ``...die noch zu wenig zurückliegt, um detaillierte Erfahrungen wirklicher Probleme anzugehen...''.

Immerhin ist in der Veröffentlichung eine Demonstration arithmetischer Grundoperationen ohne zuständige LISP-Basisfunktionen enthalten. Eine Geschwindigkeitsangabe wird ebenfalls gemacht: Danach benötigte das System für die Berechnung des Differentialquotienten von xnach x (d.h. dx/dx) etwa 5 Sekunden.

Das LISP-System auf der TREAC diente insgesamt als Erfahrungs- und Probeinstrument. Kurz darauf (vor Oktober 1961) haben Mitarbeiter von Strachey LISP aufeiner EMIDEC2400 Implementiert[McC6?][S.94].Später hat man dann (unter Teilnahme von J.M.Foster) die Listenverarbeitung unabhängig von LISP weitergeführt.

Zu Beginn der sechziger Jahre war dann die Listenverarbeitung relativ populär in Großbritannien. Eine ganze Reihe von Systemen wurde entwikkelt, die mehr oder weniger von LISP verschieden waren [FOX66, WILK65]. Unter ihnen verdientdie Sprache WISP eine besondere Erwähnung [WILK64].

LISP wurde erst aktuell, als die ersten Maschinen der IBM/7090-Reihe nach Großbritannien geliefert wurden. Es scheint so zu sein, da\ssdieInstallation einer IBM/7090 Ende 1964 am Imperial College das auslösende Ereignis gewesen ist.

Für diese Anlage wurde durch Hearn, der sich vom September 1964 bisAugust in England aufhielt, das LISP1.55-System ([MCC62c], Anhang I, [CAM66])eingeführt. Die Beweggründe dafür waren Bedürfnisse der Physiker am Imperial College und in anderen Universitäten bzw. Instituten in der Umgebung Londons, denn Hearn hatte sein Formelmanipulationssystem mitgebracht. Das ImperialCollege sollte als zentrales Rechenzentrum fungieren. Hearn hat auchwährend seines Aufenhaltes am Rutherford-Laboratorium in Didcot für die Popularisierung von LISP gesorgt.

Das System wurde bis August 1966 weiterentwickelt, um gewissen speziellen Bedürfnissen physikalischer Forschung entgegenzukommen und unter dem Namen LISP1.6 von Physikern des Clarendon Laboratoriums Oxford auf dem Rechner in London verwendet. Am Imperial College wurde dagegen eine nicht so spezialisierte Variante benutzt [CAM66].

Anfang 1967 sind zwar nicht sehr viele LISP-Programmierer tätig gewesen, aber die Anwendungsgebiete waren doch verhältnismäßig breit: Man verwendete LISP für Arbeiten an Modaler Logik, an Theorembeweisern für den Prädikatenkalkül 1. Stufe, für die Lehre, für ``mechanische'' Antropologie (inklusive Edieren von Text), für Spektroskopie, Gruppentheorie, Neurophysiologie, für die automatische ERzeugung und Testung von FORTRAN-Programmen und zur Übersetzung zwischen verschiedenen Maschinen-Codes.

Das Erscheinen des LISP1.5 Systems aus Stanford und die rege Benutzung durch die Physiker des Rutherford Laboratoriums in Didcot inspirierte Dr.D.B.Russell vom Atlas Computer Laboratorium Chilton in Didcot, ein ähnliches System für den Atlas aufzubauen.

Der Atlas Computer darf in gewisser Weise als erster Rechner der dritten Generation angesehen werden, obwohl er noch nicht mit integrierten Bausteinen ausgerüstet war. Diese an der Universität von Manchester entwickelte Maschine hat jedoch mit ihrer zukunftsweisenden Architektur alle wesentlichen nachfolgenden Rechner beeinflußt [lav78].

Die erste Version des Atlas LISP, LISPDEC66, war Mitte 1966 fertig. Sie war weitgehend kompatibel mit dem LISP1.5 auf der IBM/7090: Der Nutzer mußte lediglich die Steuerkarten für OVERLORD entfernen, und er konnte seinen Kartendeck im IBM-Format zur Abarbeitung im Atlas verwenden.

Kleinere Abweichungen waren: die Funktionen ARRAY, TIME, TIME1 undERRORSET, die Funktionen der Car-Cdr-Familie mit mehr als drei A bzw. Dzwischen C und R, sowie alle Funktionen zum Zeichenweisen Einlesen undKlassifizieren waren nicht vorhanden. Car und Cdr eines Atoms konnten nicht gebildet werden -- es resultierten Fehler. Weder EQ noch EQUAL warensinnvoll auf Gleitkommazahlen anwendbar: Die Vergleichsgenauigkeit war bis zur letzten Stelle exakt, und kleine Rundungsfehler sowie Einlesekonversionen führten zu verschiedenen Zahlen (d.h. $1 \not= 1.0$). Obwohl der erste Compiler nur ``rudimentär'' vorhanden war, hatte Russellein komplettes LAP aufgebaut, das auf der Assemblersprache des Atlas, ABL,beruhte [RUS66].

Diese Möglichkeiten nutzten R.d'Inverno in seinem System ALAM [IN69],das das bekannteste Anwendungsprogramm des Atlas LISP-System geworden ist. Das Manual [IN68] stellt gleichzeitig ein Manual für das Atlas LISP dar.d'Inverno hatte von Hearns Aktivitäten keine keine Kenntnis und fand dieMitte 1966 verfügbaren Programme zur symbolischen Rechnung für Physiker auf dem Gebiet der Gravitationstheorie zu langsam und deshalb zu schwach. Er programmierte sein relativ großes System völlig in LAP -- ein wohleinmaliger Fall der Verwendung von LISP.

Im Laufe des Jahres 1967 lernte Russell andere LISP-Implementationen kennen.Am meisten scheint ihn das BBN-LISP auf der SDS940 beeinflußt zu haben. So entwickelte er eine zweite Version des Atlas LISP (LISP68), die aber teilweise mit der vorhergehenden unverträglich gewesen zu sein schien. Wie Russell vermerkt [RUS68], konnte er für die Entwicklung des Compilers aufdas BBN-Programm zurückgreifen.

Das LISP68-System basiert auf dem Bindungsschema von LISP1.6. Wie allerdings der Compiler gearbeitet hat, ist nicht ersichtlich, denn es gab keine Deklaration für freie Variable. Einzig mögliche Erklärung ist, da\ssauch derCompiler jede Variable als freie auffaßt und Zugriff zur Wertzelle sichert. Eine ganze Reihe von Funktionen wurden offen compiliert -- unter ihnen nicht nur die gängigen FSUBR-Funktionen, sondern auch alle Mitglieder derCar-Cdr-Familie bis zur vierfachen Verschachtelung, {\tt CONS, RPLACA, RPLACD, EQ} und ATOM sowie die P-Listenfunktionen PLIST (holt die P-Liste) undASCRIBE (setzt die P-Liste) und einige numerische Funktionen ({\tt ADD, SUB,INCR = ADD1, DECR 0 SUB1}). Das System bot etwa 200 Grundfunktionen an und stellte insgesamt ein durchaus respektables Produkt dar. Der Listenraum mit insgesamt 100 Blöcken zu je 512 Worten (theoretisch bis 4096 Blöcke) ermöglichte ernstzunehmende LISP-Aktivitäten.

Noch 1967 hat eine Gruppe an der Queens University in Belfast ebenfalls ein LISP-System implementiert. Dies geschah unter der Leitung von F.V.McBridefür die ICL1905. Dieses System wurde benutzt für die Einbettung von Möglichkeiten zum Pattern Matching in LISP [MCB69].

Für einige Jahre war in Großbritannien LISP wohl nur in den Kreisen der Physiker für Zwecke der Formelmanipulation in Gebrauch. Ausnahmen sind die seltenen Benutzer der LISP1.5-Systeme auf IBM/7090 bzw. 7094-Anlagen (etwa Luckham in Manchester, vgl. [LUC67]). Die in Edinburgh entwickelteListenverarbeitungssprache POP2 hatte mehr Popularität bei den Forschern auf dem Gebiet der Künstlichen Intelligenz.

Erst Mitte der siebziger Jahre wurden dann eigene Implementierungsaktivitäten aufgenommen. Begonnen haben damit bezeichnenderweise wiederum Physiker: A.C.Norman hatte sich seit 1967 mit kleinen Systemen für die pdp-7 an derUniversität von Cambridge beschäftigt. Die Erfahrung mit diesem Systemen und die nicht befriedigten Wünsche an verschiedenen anderen LISP-Systemen führten zum Entwurf eines eigenen leistungsfähigen Systems für die IBM/360-/370.

Das Projekt startete etwa 1974. Folgende Grundentscheidungen wurden vor dem Programmentwurf gefällt: LISP1.6-Bindungsschema, Typcharakteristika in den Zeigern auf ein Objekt statt im Objekt selbst, kompaktifizierendes Garbage Collection, umfassende arithmetische Möglichkeiten, sorgfältige Gültigkeitsprüfungen innerhalb jeder Funktion. Eine methodologische Entscheidung beeinflußte die Programmerstellung wesentlich: Man wollte BCPL als Implementierungssprache nutzen.

Der Bericht [FIT77] über die fertiggestellte Implementation beschreibt eininteressantes System, dessen Leistungsvermögen nicht wesentlich unter dem des handcodierten STANFORD LISP/360 liegen. Während der Interpreter etwa 25\% langsamer arbeitete, waren compilierte Programme etwa 20\% schneller. Wurde die Arithmetik exzessiv genutzt, konnte sogar ein Faktor 2 (200\%) erreicht werden.

Eine weitere eigenständige Aktivität in Großbritannien war die Implementierung von InterLISP für die ICL-4 in Edinburgh um 1978. Unter der Leitung von G.Miller wareneinige Schwierigkeiten zu überwinden, etwa ein Fehler im Garbage Collection. Als das System fertig war, wurden DEC-10-Anlagen nach Edinburgh geliefert, so da\sskeine Benutzer des ICL-4-InterLISP bekannt geworden sind.

 

Frankreich

Im Frankreich begann man, wie in Großbritannien, Anfang der sechziger Jahre mit Arbeiten auf dem Gebiet der Künstlichen Intelligenz. Die mit LISP verbundene Tätigkeit begann zunächst nicht sehr erfolgversprechend: J.Pitrat verfügte in Paris über eine IBM 704 (am Institut Blaise Pascal, vgl. [FIN66]) und wollte mit LISP arbeiten. Eine Bitte um Hilfe an McCarthyerreichte den Adressaten nicht oder wurde nicht akzeptiert, jedenfalls kam keine Antwort. So bemühte sich Pitrat um FLPL und arbeitete damit.

1966 hatte Kent sein LISP-System auf die CDC3600 an das gleiche Institutgebracht. Es wurde hauptsächlich für die Formelmanipulation genutzt.

Seit 1962 war in Grenoble eine IBM 7044 in Betrieb. Von Anfang an war hier LISP1.5 verfügbar. Etwa 1963--64 brachte T.Evans eine neuere LISP Versionaus Cambridge mit und hielt einen Programmierkurs. Das System wurde bis zum Abri\ssder Anlage 1968 von einem kleinen Nutzerkreis verwendet. 1963 wurde einALGOL-Compiler durch eine Gruppe von Programmierern und Wissenschaftlern unter der Leitung von J.C.Bousard aufgebaut. Diese Basis wiederum wurdedurch J.Cohen und seine Mitarbeiter für eine LISP-Implementation genutzt[CO65]. Seit etwa Anfang 1964 konstruierte man ein System vonALGOL-Prozeduren für die Einbettung von LISP in Algol60[CO67b].

Im Laufe des Jahres 1965 wurde dieses System sowohl für Arbeiten zur Symbolmanipulation (als Anwendungsgebiete werden Formelmanipulation und Theorembeweisen angegeben) als auch für Experimente zur Verwendung externer Speicher innerhalb einer LISP-Umgebung benutzt. Diese Experimente fielen recht ermutigend aus, da eine gewisse Lokalität der Arbeitsmengen von Listenseiten festgestellt werden konnte [CO67a].

In seinem Bericht über die Auslastung des IBM 7044-Systems konnte Bousardberichten, da\ss5\% der gesamten Rechenzeit an Benutzer von COMIT, COBOL oderLISP ging [BOU66].

Zwischen 1966 und 1968 scheint die LISP-Aktivität in Grenoble fortgeführt worden zu sein. Ein Indiz dafür ist einmal das Buch von Ribbens [RIB69],der in dieser Zeit Grenoble besuchte, zum anderen die weitere Geschichte: {\sc Y. Siret} nutzte die erste Gelegenheit, die sich ihm bot, um 1968 aus den USA ein STANFORD LISP/360-System nach Grenoble mitzunehmen, als man dort eine IBM/360--67 aufstellt hatte. Dort wurde es an die örtliche Modifikation des Betriebssystems CP/CMS angepaßt. Siret wechselte das Institut 1971. Mitseinem Abgang wurden alle Aktivitäten vernachlässigt und hörten auf.

1973 ist dieses System dann von A.Lux betreut worden, der die wildgewachsenen Programmstrukturen etwas ordnete. Er promovierte 1975 mit einer Arbeit über die LISP-Implementation unter Verwendung einer virtuellen LISP-Basismaschine [LUX75a]. Er benutzte diese Ideen für die Konstruktion des neuen LISP-Systems von Grenoble, das nach Ablösung der alten IBM/360-67 auf der IRIS80 lief ([LUX78], vgl. auch [LUX75b]).

Seit etwa 1970 besteht die Gruppe von P. Greussay an der Universität Paris8 (Vincennes). Man begann 1971 mit der ersten eigenen Implementation: Ein LISP-System für den CAE-510, einen heimischen 18Bit/8K-Rechner. Dieses System hatte viele Charakteristika von LISP1.6 [GREN72].

Die Erfahrungen mit dem kleinen Rechner führten zu Ideen bezüglich der Verbesserung der Interpretation (keine CONS-Operation während derInterpretation auf Grund von Systemanforderungen usw.). Kurz darauf wurde ein Tischrechner CAB-500 mit 16K Trommelspeicher und 32 Bit.Worten als Basis für eine erneute LISP-Implementation gewählt.

Die inzwischen erreichten Verbesserungen führten zur Ansicht, da\ssman eineeigenständige Weiterentwicklung erreicht habe: Also gab man denn verbesserten System auf dem Minirechner CAE-510 den Namen VLISP (von Vincennes LISP). Neben den üblichen Methoden zur Platzeinsparung undBeschleunigung hatte Greussay den Begriff des Musters für dieInterpretation von LISP erweitert zum zog. Filter [GREU76].

1974 erhielt die Gruppe, zu der inzwischen auch {\sc H.Wertz, J.Chailloux, D.Goossens} und andere gehörten, die Möglichkeit, eine Telemechanique T1600 am Institut de l'Environment zur LISP-Implementation zu benutzen. Dieses System wurde etwa 1975 abgeschlossen [GREU75].

Greussay formulierte die grundlegenden Ideen von VLISP 1976, als man gerade begann, VLISP auf einer pdp-10 zu implementieren [GREU76].Mitte 1976 ist dieses System fertiggestellt worden [CHA76]. VLISP-10, wie esgenannt wurde, war ein recht umfangreiches System. Es enthielt etwa 200 Basisfunktionen und eine Reihe nützlicher Hilfsmittel, wie das Testsystem PHENARETE [WER76,77,78], das mit DWIM und anderen ähnlichen Erzeugnissenvergleichbar war.

Die Datentypen umfaßten Atomsymbole (bis 18 Zeichen), Zeichenketten, ganze Zahlen und Listen. Die Funktionstypen waren SUBR, NSUBR (wie LSUBR inLISP1.6), FSUBR, EXPR, FEXPR und zwei Makrotypen: MACIN und MACOUT.Durch Notieren eines Atoms an der Stelle der Variablenliste konnte, ähnlich wie ein MacLISP, eine LEXPR-Verarbeitung initiiert werden. Allerdings bot VLISP nicht die Hilfsfunktionen SETARG bzw. ARG an, sondern wies demAtom die gesamte Argumentliste zu.

Unter den Funktionen fallen folgende Neuentwicklung auf: EPROGN bekommtals Argument eine Liste von Ausdrücken, die sequentiell ausgewertet werden. Wie bei PROGN bestimmt der letzte Ausdruck den Gesamtwert. Eine FunktionIF mit n Argumente bietet einfache COND-Möglichkeiten: Wenn das ersteArgument bei der Auswertung nicht NIL ergibt, liefert die Auswertung deszweiten Arguments den Gesamtwert. In den übrigen Fällen (erstes Argument {\tt = NIL}) werden die Argumente 3 bis n sequentiell ausgewertet und der Wert desletzten als Gesamtwert benutzt.

Daneben standen Funktionen zur Selektion (SELECT und SELECTQ) undzyklischen Auswertung (WHILE, UNTIL und REPEAT). Zwei Funktionen dienenzu globalen Exits: ESCAPE und LESCAPE. Während ESCAPE als erstesArgument ein Atom als Exitfunktionen eingeführt, deren Aufruf den gesamten ESCAPE-Ausdruck beendet, gleichgültig wie tief dieser Aufruf verschachteltist, dient LESCAPE dazu, den letzen LAMBDA-Ausdruck zu verlassen.

VLISP enthielt eine Reihe von Funktionen und ein großzügiges Sortiment von Grundfunktionen zur Listenverarbeitung. Ein nur dem Nutzer zugänglicher Keller konnte mit zwei Zugriffsfunktionen PUSH und POP verwaltet werden.Die arithmetischen Funktionen hatten teilweise ungewöhnliche Namen, das Spektrum entspricht etwa LISP1.6.

Bei der Ein- und Ausgabe wurde wiederum etwa der LISP1.6-Standard geboten. Neu sind die Ein- und Ausgabemakros: Zum Beispiel konnte mittels DMI einEingabemakro definiert werden:

      (DMI IF (B THEN . ELSE)}
        (LIST 'COND(LIST B THEN) (CONS T ELSE))).

Immer wenn nun IF eingelesen wird, wird das darauffolgende Element zu Bgebunden, das nächste Element zu THEN und der gesamte Listenrest zu ELSE.Dann wird der Funktionskörper ausgewertet, und das Resultat gilt als Einleseergebnis. Liegt z.B. der Ausdruck

\begin{center}(IF(GT A B) (SETQ X B) SETQ X A) (INCR Y))\end{center}

an, ergibt sich:

         (COND ((GT A B) (SETQ X B))
               (T (SETQ X A) (INCR Y))).

Ähnlich, nur bezüglich der Ausgabe, verläuft die Arbeit mit den Ausgabemakros: Durch

\begin{center}(DMO QUOTE X (PRIN1 (QUOTE ') X))\end{center}

kann erreicht werden, da\ssauch bei der Ausgabe statt des Atoms QUOTE derApostroph ankommt.

Die Zeichenkettenmanipulation basierte auf den üblichen Basisfunktionen zur Typprüfung, zur Umformung von Zeichenketten zu Listen, zum Vergleich, Zusammenhängen, Duplizieren, Umkehren von Ketten sowie zur Suche von Teilketten, zur Ersetzung solcher und zur Ermittlung ihrer Position innerhalb einer umfassenden Zeichnenkette.

Hochinteressant ist, da\ssVLISP eine Ausgabemöglichkeit in Braille-Schrift hatte.

An dem fertigen VLISP wurden natürlich weitere Verbesserungen vorgenommen. Etwa im Mai 1977 konnte eine Beschreibung der neuen Möglichkeiten vorgelegt werden [CHA77], die nun auch Gleitkommazahlen, Verarbeitungsmakros (mit DMdefiniert) und Felder (mit DA definiert) umfaßten. Zusätzlich sind dieHilfsprogramme (Editor, Phenarete, Fehlerkorrektur) und der Compiler (samt LAP) verbessert bzw. überhaupt erst eingesetzt worden.

Mit diesem System hatte man nun ein fortgeschrittenes Arbeitsmittel in der Hand. Die Erfolge bei der Implementierung haben zu weiteren Schritte ermutigt (Implementierung von VLISP für den Mikroprozessor Intel8080) und Überführung des pdp-10-Systems auf eine DEC-20 an der Open University in England.

Die Forschungsgruppe unter Greussay war seinerzeit eine der aktivsten inEuropa. Dies zeigt auch die Herausgabe des LISP-Bulletins durch Greussayim Sommer 1978.

Neben Paris mu\ssToulouse erwähnt werden, wo unter J. L. Durieux eineLISP-Implementation TLISP entstanden ist [DU].

Theoretische Arbeit über LISP wurde außerdem in Paris-Rocquencourt [DER77a,DER77b] geleistet.

 

Niederlande

In den Niederlanden wird die LISP-Geschichte von zwei Personen bestimmt, von W.L.van der Poel und G.van der Mey.

Obwohl van der Poel den Artikel [MCC60c] zur Kenntnis nahm, schien erzunächst LISP nicht allzu interessant zu finden. Jedenfall beauftragte er entweder 1962 oder 1963 van der Mey, einen Interpreter für dieProgrammiersprache IPL-V zu schreiben. Während dieser an dem Programm arbeitete, hatte van der Poel die Gelegenheit, einen längeren Aufenthalt imHerbstsemester 1964 an der Standford Universität zu verbringen. Dort wurde er von McCarthy mit LISP richtig bekannt gemacht. Das Studium derAnwendungsfälle und die Einfachheit der Sprache begeisterte ihn so, da\sserbei seiner Heimkehr mit der enthusiastischen Nachricht, er habe eine viel schönere Programmiersprache entdeckt, zu van der Mey fuhr.

``Er gönnte sich keine Zeit mehr, mein IPL-Programm zu testen, sondern beauftragte mich, einen Interpreter für LISP1.5 zu schreiben zwecks Verwendung auf der Maschine pdp-8'' [MEY78]. Hier erinnert sich {\sc van derMey} nicht ganz korrekt: Das erste System war nach van der Poel für dieZEBRA bestimmt.

Dieses Programm war 1965 fertig und wurde zunächst noch im Labor der Niederländischen PTT erprobt. Es war ein relativ bescheidenes Programm, das nur einen 1K-Listenspeicher bot. Viele der sonst üblichen Basisfunktionen waren weggelassen worden, aber die Mitglieder der Car-Cdr-Familie bis zur 11-fachen Verschachtelung waren vorhanden. Kurz darauf wurde die pdp-8-Implementation begonnen.

Der Nutzer arbeitete in beiden Systemen mit EVALQUOTE, mußte also Paareliefern: Funktionen und Liste von Argumenten. Diese Eingaben wurden als Lochstreifen oder direkt vom Fernschreiber akzeptiert. An der Implementierungstechnik ist interessant, da\ssder Kellerspeicher innerhalb desListenspeichers lag; ``Tatsächlich ist der Keller selbst als Liste im normalen Listenspeicher organisiert...'' [MEY67]. Die kompliziertenSpeicherplatzprobleme hatte man dadurch zu lösen versucht, da\ssalleStandardatome gleichzeitig Funktionen bezeichneten. So hat die Funktion NIL beliebig viele Argumente und liefert immer NIL, die Funktion That ein Argument und liefert dessen Wert, die Funktion APVAL wird fürdie Suche von Leerzeichen auf dem Eingabelochstreifen verwendet usw. usf. EXPR wurde sogar als Mehrzweckfunktion eingesetzt, mit der an einebestimmte Stelle des Hauptspeichers gesprungen werden konnte, um dort ein Codestück abzuarbeiten. Hier konnte sich der Nutzer eigene Befehlsfolgen bereitstellen, er hatte aber auch gewisse Standardvarianten. Zu diesen gehörten: Umschalten in Zustände, um Zahlen oktal bzw. dezimal zu akzeptieren oder auszugeben, maskieren oder logischen Verknüpfungen von Zahlen, Drucken einzelner Zeichen usw.

Für die Systemfunktionen hatte man statt der P-Liste den Wert ihres Atomzeigers zur Repräsentation der interessierenden Eigenschaft (Beginn des Codes) benutzt.

Eine besondere Neuerung war auf Grund der Funktionsdefinitionen für NIL undT möglich: Man konnte bedingte Ausdrücke schreiben, ohne COND alsFunktionsnamen anführen zu müssen: Eine Ausdrucksfolge wie \begin{center} ((NULL X) (RETURN Y))

((NULL Y) (RETURN X))

(T (RETURN (CONS X Y))\end{center} war erlaubt, und wurde wie folgt abgearbeitet: Zunächst wird (NULL X)ausgewertet, um die Funktion für den ersten Ausdruck zu ermitteln. Angenommen, es ergäbe sich NIL. Die Funktion NIL aber liefert NIL, ohneihre Argumente weiter zu betrachten. So kommen wir zum zweiten Ausdruck. Hier geschieht ähnliches. Die Funktion T schließlich wertet ihr Argument ausund löst auf diese Art das RETURN aus.

Van der Meys pdp-8-LISP wurde etwa 1968 in die Bibliothek derNutzergemeinschaft der Firma Digital Equipment, DECUS, aufgenommen [MEY68]und galt lange als Vorbild für LISP-Implementation auf Kleinstrechnern [NAK69].

Im Laufe des Jahres 1966 bekam das Labor der PTT eine Electrologica-X8. {\sc Van der Poel} schlug van der Mey vor, auch für diese wesentlich größereMaschine ein LISP-System aufzubauen.

Van der Mey wollte die LISP-Implementation nicht zur Routine werden lassen,und er dachte über Verbesserungen nach, die bis in das Sprachniveau reichten. Hier schienen ihm besonders bestimmte Beschränkungen bei der Ein- und Ausgabe von zyklischen Listen bzw. von Listen mit physisch identischen Unterlisten änderungsbedürftig. in der Tat kann man ja mittels RPLACD oder RPLACAleicht Strukturen erzeugen, die nicht in der S-Sprache notierbar sind.

Da in der EL-X8 genügend freie Bits zu Markierungszwecken frei waren, konnte van der Mey ein Druckprogramm entwickeln, in dem die auszugebende Strukturzunächst auf identische Zweige abgesucht wird, dann die Listen und die mit Marken versehenen Unterlisten ausgegeben werden und schließlich die Struktur wieder auf ihren originalen Stand gebracht wird.

So wird die Liste, deren Elemente (A B), A und B sind, als

\begin{center}((A B) A B)\end{center}

ausgegeben. Vollführen wir aber ein

\begin{center}(RPLACD Liste (CAR Liste)),\end{center}

dann ergibt sich in allen konventionellen Systemen die gleiche Zeichenkette beim Ausdrucken. Im EL-X8-LISP wird nun jedoch gedruckt:

\begin{center}((3000: A B) :3000)\end{center} [KAL75][S.105].

Merkwürdigerweise hielt van der Mey dieselbe Markierung für das GarbageCollection als Verbesserung gegenüber der Markierung im pdp-8-LISP.

Das EL-X8-System ist etwa 1967 fertiggestellt worden [POE67]. Es wurde unteranderem 1968 nach Kiel geliefert [kal75].

Der verfügbare Maschinenpark wechselte, als van der Poel 1968 zum Professoran der Technischen Hochschule in Delft berufen wurde. Dort besa\ssman nebender pdp-8 auch eine pdp-9. Es war klar, da\ssvan der Poel, derListenverarbeitung in sein Vorlesungsprogramm aufnahm [POE72], auch für dieseAnlage eine Implementation wünschte.

Zunächst hat man (möglicherweise C.F.Knoet) einfach das LISP-System vonder pdp-8 umgeschrieben [MEY70b]. Doch van der Mey hatte neue Ideen: Erwollte die gegenüber der pdp-8 frei verfügbaren drei Bits verwenden, um eine kompakte Listenrepräsentation zu verwirklichen. Es ist nicht unwahrscheinlich, da\sszu diesem Vorhaben nicht nur die Speicherknappheit am Rechner, sondern auch die Veröffentlichung von W.J.Hansen von 1969 [HAN69] beigetragen hatte.

Man ging davon aus, da\ssin den meisten Fällen nur echte Listen verwendetwerden. Wenn man diese physisch dicht abgespeichert, zeigten die Cdrs grundsätzlich auf die nächste Zelle, d.h. auf das nächste Maschinenwort. Nur der letzte Cdr enthält NIL. Diese Listen wurden so dargestellt, da\ssnur dieCars Worte zugeordnet bekamen, und zwar mit Markierungen, die anzeigten, da\sses sich um ein echtes Listenelement handelt. In das letzte Element wurde zusätzlich der Vermerk gebracht, da\ssder zugeordnete Cdr NIL ist. In derTerminologie van der Meys konnte also jede normale Liste durch offene Zellenund Endzelle repräsentiert werden [MEY71].

Probleme entstanden nun jedoch bei den Operationen CONS und RPLACD. Manlöste diese, indem Brückenzellen eingeführt wurden, die die physischverstreuten Listenteile koppeln. Um die Vorteile der linearen Anordnung nicht durch die nicht vorhersagbaren Verarbeitungsoperationen einzubüßen, wurde ein linearisierender Garbage Collector programmiert. Dieser markiert zunächst die aktiven Zellen, schiebt dann den gesamten Listenspeicher zusammen und kopiert die Listen in den freien Raum, um sie zu linearisieren.

Dieses System, HLISP genannt [MEY70a], war etwa 1974 funktionsfähig. {\sc Van derMey} entdeckte, da\ssdie reguläre lineare Anordnung der Listen Möglichkeitenfür eine beschleunigte Abarbeitung rekursiver Prozesse bot [MEY71]. Erveröffentlichte seine Ideen im selben Jahr.

Seit dieser Zeit ist van der Mey nicht mehr so direkt mit derLISP-Implementation verbunden.

Unter van der Poel wurden in Delft die Arbeiten jedoch fortgesetzt. So istwohl das pdp-8-LISP verschiedentlich umgeschrieben und effektiviert worden. Möglichkeiten dazu boten hauptsächlich verbesserte Hauptspeicherverhältnisse: Eine Version für 8K wurde von A.Kooiman und M.R.Vlendr\'e erarbeitet,eine andere, wesentlich überarbeitete (Cars und Cdrs treten nicht direkt benachbart auf, sondern in zwei getrennten Feldern) für 16K durch A.J.Mesman und H.W.van der Poel, den Sohn W.L.van der Poels[MEY74].

1974--1975 betreute van der Poel die Promotionsarbeit von K.Müller überkonkurrentes Garbage Collection [MUE76]. Diese Arbeit wurde im August 1975abgeschlossen und entstand unabhängig von den etwa gleichzeitigen Arbeit {\sc Steele}s [STE75] und einer Gruppe um Dijkstra [DI75] (s.u.). MüllersBemühungen beziehen sich nicht speziell auf LISP, sondern sind auf beliebige Datenstrukturen anwendbar, ermöglichen aber vergleichsweise weniger parallele Arbeit als die anderen Autoren.

1977 erstellte M.den Hoed eine LISP-Implementation für die pdp-11 [HOE77].Er benutzte dazu die Systemprogrammiersprache HARVALIAS [EY75]. Dieses Systemberuhte weitgehend auf den pdp-8-Systemen, indem es wie diese Wertzellen hatte, beim Einlesen und Drucken zirkuläre Strukturen erlaubte und gleichartige Funktionsdefinitionen für NIL und T benutzte.

Die Arbeit der Gruppe um Dijkstra, in der die Niederländer {\sc A.J.Martin, C.S.Scholten} und E.F.M.Steffens mitwirkten, an derEntwicklung eines hochgradig parallel neben dem Listenverarbeitungssystem arbeitsfähigen Garbage Collector, soll zum Ende angeführt werden. Sie ist zwar nicht direkt für eine LISP-Implementation gedacht, wird aber sicher zukünftige Arbeiten beeinflussen.

 

Norwegen

In Norwegen begann man sich etwa ab 1965 für LISP zu interessieren. Vermutlich bestanden von Oslo Verbindungen zu K.Korsvold, der in StanfordFormelmanipulation mit LISP betrieb. L.Monrad-Krohn beauftragte {\sc JanKent}, eine Masters-Thesis über LISP-Implementation zu schreiben und die Implementation ander verfügbaren CDC3600 durchzuführen. Kent hatte Zugriffzu einem Listing des 7090-LISP (welcher Version ist nicht mehr klar), und er hielt sich bei seiner Programmierung weitgehend an das Vorbild. Im Dezember 1966 war das System hinreichend stabil, und Kent schlo\ssseine Prüfungen fürden Master of Science in Mathematik ab. Die schriftliche Arbeit, die praktisch eine Beschreibung des LISP-Systems für die CDC3600 darstellte [KEN66], wurde alsInterner Report des Norwegischen Forschungsamtes beim Verteidigungsministerium veröffentlicht.

Nach kurzer Zeit, d.h. noch 1966, wurde Kents System schon durch dieBenutzer-Organisation der CDC-Rechner, CO-OP, vertrieben. Kent selbst hatte seine Arbeit an der Maschine in Kjeller in Norwegen durchgeführt. Er selbst brachte es zum Institut Blaise Pascal nach Paris, zur Technischen Hochschule nach Stockholm und an die Universität von Uppsala.

Anfang 1967 fuhr Kent in die USA und nach Kanada. Er nahm dasCDC3600-LISP-System mit und hat es selbst in der Michigan State University sowie an der University of Waterloo in Kanada installiert. Das CDC36000-System mu\ssweithin genutzt worden sein. Von der Systembeschreibung wurden über 100Exemplare gedruckt, und alle wurden an Nutzer versandt.

In Waterloo hielt Kent eine Vorlesung über Listenverarbeitung und beganneine LISP-Implementation für die dortige IBM/360-40 zu planen. Seine Ideen sollten in dem dann nicht erschienenen Buch von Berkeley und {\sc Edwards} ``The nature, use and implementation of the computer programming language LISP'' veröffentlicht werden [KEN67, BE67].

Gemeinsam mit J.F.Bolce und R.H.Cooper von Waterloo begann Kent dannmit der Implementation auf der IBM/360. Nachdem das System weitgehend lauffähig war, wurde Kent nach Stanford eingeladen, um auf der dortigenMaschine die Implementation abzuschließen. Zusammen mit Berns wurdedann im Laufe des Jahres das System fertiggestellt, das später unter dem Namen STANFORD LISP/360 bekannt wurde (siehe S.?). In Waterloo haben Bolce und Cooper den Interpreter für die IBM/360 ebenfalls in dergleichen Zeit fertiggestellt [BOL68]. Beide Systeme dürfen als identischbetrachtet werden. Allerdings hat Berns, wie schon an anderer Stellevermerkt, noch eine längere Zeit in Stanford das System verbessert.

Etwa 1968--69 kehrte Kent nach Oslo zurück. Dort wurde nun er an derUniversität von Oslo der Auftraggeber für eine Masters-Arbeit. Diesmal hie\ssder Student E.Holbaek-Hansen. Die Aufgabe bestand darin, ein LISP-Systemfür die CDC3300 zu entwerfen und zu programmieren. Diese Arbeit wurde etwa Ende 1970 beendet und durch die Universität in Oslo publiziert [HOL71a].Anfang 1971 konnte man im Ausland das LISP3300 beziehen -- dies ist belegt für die Universität Erlangen-Nürnberg.

Obwohl dieses LISP-System nicht zu einem sehr großen Nutzerkreis gelangte, wurde in Oslo daran weitergearbeitet. Graduierte Studenten hatten ihren Anteil an dieser Weiterentwicklung -- doch scheint Holbaek-Hansen den Hauptanteilgetragen zu haben. Die Nutzerhandbücher von 1972 [GOE72] bzw. 1973 spiegelndiese Entwicklung wieder [HOL71b].

Etwa 1973 wurde das System um ein LAP und einen Compiler (Minicomp)erweitert [HOL74a]. Schließlich lag Ende 1974 eine insgesamt überarbeiteteVersion vor [HOL74b]. Sie enthielt zwei Compiler: Den Minicomp, einenkleinen, eingeschränkten, aber extrem effizienten Compiler und einen größeren, umfangreicheren, über den aus [HOL74a] nicht viel zu entnehmen ist. BeideCompiler waren in LISP programmiert -- ebenso wie der LAP-Übersetzer.

Eine weitere LISP-Implementation unter der Aufsicht Kents wurde Ende 1973begonnen: A.Eide und H.K.Langva erstellten ein LISP1.5-System für denCYBER-74. Ihre Masters-Arbeiten wurden 1974 publiziert [EID74,LAN74].

1976 arbeitete Kent an einer LISP-Implementation für Microrechner.

Sein System für die CDC3600 soll auch das Vorbild für verschiedene Implementationen für die CDC3400 gedient haben.

 

Schweden

Im Laufe des Jahres 1967 bezog die Universität in Uppsala das LISP1.5-System für die CDC3600. Man begann mit der Benutzung für einfache Probleme und für die Lehre. Ab 1968 versuchten einzelne Studenten, das System zu verbessern. So wurde am Compiler, am LAP [MAK69] und am Laufzeitsystem [NOD68]gearbeitet. Etwa Mitte 1969 war soviel geändert, da\ssein neues Manualherausgegeben werden mußte [U70].

Nachdem man einige Kenntnis über LISP hatte, begann man, das existierende System kritischer zu sehen. Sandewall hielt sich einige Zeit in den USAauf, und auch Urmi war 1970 bei BBN in Cambridge. Man plante einLISP-System für einem Siemens 305, doch der Rechner kam und kam nicht an. Um auch an anderen Rechnern in Schweden per RAX-Fernverarbeitung arbeiten zu können, verfiel man auf die Idee, ein LISP-System in FORTRAN zu erstellen. Damit wurde im Januar 1970 angefangen, und im September hatten M.Nordströmund Sandewall ein einigermaßen akzeptables System in FORTRAN IV fürIBM-Maschinen geschrieben [NOD70].

Dieses System wurde kurz darauf durch einen Editor und die TRACE-Funktion,die von D.Breslaw stammten, erweitert. LISP F1 war zwar für dieinteraktive Arbeit gedacht, konnte aber auch im Stapelbetrieb laufen. Es entsprach etwa LISP1.5, enthielt aber schon gewisse Erweiterungen aus dem Vorrat von BBN-LISP, wie no-spread-LAMBDA-Ausdrücke, BREAK-Funktionensowie Nutzerkontrollierbare Fehlerbehandlung.

Der Speicherbedarf beruhte auf den für das Programm und dessen Arbeitsspeicher erforderlichen 36K Bytes, zu denen der dynamische Speicherplatz hinzukam (ca. 45K und mehr). Die Namen waren auf acht Zeichen begrenzt; Gleitkommazahlen waren nicht verfügbar. Der Nutzer konnte zwischen dem EVAL-Modus und dem EVALQUOTE-Modus wählen. Das System bot 75Funktionen, unter denen die Definitionsfunktionen DE und DF hier wohl zumerstenmal auftreten. Sie sind später in viele andere LISP-Systeme aufgenommen worden.

Als Urmi von BBN zurückkehrte, begann er mit der Implementierung einesBBN-LISP-ähnlichen Systems für den Prozeßrechner Siemens 305. Dieses System verfügte über keinen Compiler, erlaubte aber das Studium interaktiver Arbeit.

Im Januar 1970 gründete Sandewall gemeinsam mit acht interessiertenForschern (unter ihnen Nordström, Urmi, O.Willen und A.Haraldson)das Datalogilaboratoriet. Man wollte vor allem Probleme von Frage-Antwort-Systemen, Formelmanipulation und soziologischen Modellen bearbeiten [DAT70]. An dem Siemens-System, das ähnlich wie BBN-LISP alsseitenorientiert gedacht war, arbeiteten neben Urmi auch Haraldson undBreslaw. PILS (Paged Interactive LISP System) sollte in einemvirtuellen 21-Bit-Adressraum arbeiten und mindestens vier Benutzern gleichzeitig Zugriff bieten.

Man hatte mit BBN über die Lieferung vieler Systemprogramme Abmachungen getroffen -- so konnte man ganze Subsysteme, wie den Editor, DWIN undProgrammer's Assistant, übernehmen. Obwohl geplant, wurde, nach Angaben von Urmi, der Compiler nicht fertiggestellt. Das gesamte System für die Simens305 galt 1972 als abgeschlossen [DAT75].

Ursache für diese unerwartete Beendingung des PILS-Projekts war die Planung des Kaufs einer IBM/370 durch die Universität von Uppsala, die seit Sommer 1971 diskutiert wurde. Ende 1971 entschlo\sssich die Gruppe dann, auf dieserAnlage eine leistungsfähige LISP-Implementation aufzubauen, in der ihre bisherigen Erfahrungen angewendet werden könnten, d.h. ein BBN-LISP-verträgliches System zu konstruieren, das auf einem Software-Paging-Mechanismus beruht.

Das Projekt wurde gemeinsam mit dem Universitätsrechenzentrum von Uppsala (UDAC) geplant und sorgfältig vorbereitet. Die Anlage, eine IBM/370.155, konnte seit Ende 1971 für die Implementationsarbeiten genutzt werden. Dennoch benötigte die Gruppe, die aus Urmi, M.Andersson und B.Jansson bestand, noch bis etwa 1975, bis alle Schwierigkeiten überwundenwaren. Insgesamt wird gewöhnlich ein Aufwand von 3 bis 5 Mann-Jahren angegeben.

Der Vertrieb des Systems, das seit 1974 InterLISP 360/370 [U75] hieß, wurdevon UDAC übernommen. Für 40 000 schwedische Kronen wurde es weiterverkauft, wobei ein gewisser Prozentsatz an BBN abgeführt werden mußte. Bekannt ist die Lieferung an die Universität Zürich, die Medizinische Hochschule Hannover, das LAAS in Toulose und das Weizmann-Institut in Israel.

1974 wurde von Siemens in München der Vorschlag gemacht, InterLISP/360-370 auf Anlagen des Typs Siemens 4004 überzuführen. Da die Maschinen mit gleicher innerer Struktur und identischer Assemblersprache arbeiten, glaubte man, da\ssdie Überführung innerhalb kurzer Zeit bewältigt sein könnte. Es stellte sich jedoch heraus, da\ssgewisse tückische Unterschiede der Betriebsysteme dieTransportation komplizierten.

Obwohl laut Urmi nur einige Wochen erforderlich waren, diese Probleme zulösen, übernahm Siemens erst im Herbst 1977 die Eigenverantwortung.

Im Laufe des Jahres 1977 wurde das InterLISP-System auch nach Japan geliefert. Zunächst (im Oktober 1977) lief es auf einer IBM/370.158 der Fujitso Ltd. und einer anderen IBM/370.138; im Februar konnte es auf Anlagen des Typs Fujitso M160 bzw. M190 übernommen werden.

Auch das FORTRAN-System F1 wurde weiter gepflegt. Zunächst gelangen bedeutende Steigerungen der Effizienz [DAT74], dann kodierte Nordströmim Sommer 1973 ein vollständig überarbeitetes System. Dieses System war nun dreimal schneller, bot einige der üblichen LISP-Funktionen anderer Systeme für die Ein- und Ausgabe und weitere für die Ein- und Auslagerung verteilt worden: Schon 1976 (2.1) betrug die Anzahl der Nutzerinstallationen über 96 ([DAT75], S.20).

In einem erneuten Anlauf wurde im Sommer 1976 ein Subset von InterLISP in FORTRAN kodiert (LISP F3). Auch diesmal war Nordström der Autor. LISP F3enthielt etwa 100 Basisfunktionen und eine ganze Reihe von Programmpaketen von InterLISP wie EDIT, MAKEILE, BREAK, ADVISE und TRACE sowie ein Paketsonstiger grundlegender Funktionen.

Seit 1975 haben sich die Forscher getrennt: Eine Gruppe unter Sandewallwechselte von Uppsala nach Linköping. Die Arbeitsgebiete sind aber weiterhin mit LISP verbunden. Sandewall hat sich methodologischen Aspekten derLISP-Programmierung zugewandt [SAN75b,SAN76,SAN78]. Urmi vollendete seinePromotionsarbeit [U78], ebenso Haraldson [HAR77a]. Das InterLISP/360--370wurde etwa 1978 zur weiteren Pflege an das Weizmann-Institut nach Israel weitergegeben.

Mit dem Import amerikanischer Maschinen sind natürlich auch weitere LISP-Systeme nach Schweden importiert worden. Belegt sind STANFORD LISP7360, STANFORD LISP1.6 und InterLISP auf DEC-20.

 

Bundesrepublik Deutschland

Etwa 1962 sind die ersten Anlagen des Typs IBM7090 in die Bundesrepublik geliefert worden. Für die zweite Maschine, die an die Gesellschaft für Mathematik und Datenverarbeitung (GMD) in Bonn ging, besorgte C.A.Petri mit Hilfe seinerprivaten Verbindungen zum MIT ein LISP1.5-System. Dies wurde Anfang Januar 1964 erprobt, doch meint Petri, dies und ``die auf Grundlage der damalsvorliegenden Veröffentlichungen von Studenten in den Übungen (in FAP-Makros) z. T. erfolgreich erstellten Versionen können nicht als `Übernahme in die BRD' angesehen werden'' [PEI78].

Anfang 1964 schickte Hearn ein Magnetband mit LISP1.5 und seinem begonnenenFormelmanipulationssystem an den Physiker Weicksel am Institut fürtheoretische Physik der Universität Mainz. Es ist nicht bekannt, ob damit gearbeitet wurde. Mitte des gleichen Jahres kam Hearn selbst mit einerneuen Version. Er benutzte die IBM7090 in Darmstadt, und es ist sehr wahrscheinlich, da\ssauch nach seinem Aufenthalt weitergearbeitet wurde.

Im Institut für Instrumentelle Mathematik an der Universität Bonn wurde LISP1.5 auf der Rechenanlagen IBM7090 im Jahre 1965 zum allgemeinen Gebrauch installiert; es war frühestmöglich über SHARE oder European Pogram Library beschafft worden. Im Wintersemester 1965/66 wurde das ``Seminar Datenverarbeitung'' vorwiegend der Einführung in LISP und praktischen Übungen hierzu gewidmet; in den folgenden Semestern war LISP1.5 regelmäßiger Bestandteil von Vorlesungen.

Die erste selbständige LISP-Implementation (bzw. Adaption) in Deutschland ist nach 1967 durch H.D.Baumann in Geesthacht für eine CDC3400 durchgeführtworden. Er richtete sich nach den Ideen Kents und dessen Implementation fürdie CDC3600.

Etwa 1967 begann H.Hünke in Bonn mit einer LISP-Implementation für die IBM/360.Auf Grund der Arbeiten von Genrich bezüglich METEOR versuchte er, diesesSystem von Anfang an zu integrieren. Das System IDOL, ein {\em interaktivesdisplayorientiertes Listenverarbeitungssystem}, lief in dem von der GMD selbst aufgebauten Betriebssystem B.I.T.S. [HUE68]. Dieses durchaus nichtuninteressanten System scheint allerdings keine lebhafte Verwendung gefunden zu haben.

Über die Verwendung des LISP1.5 in Darmstadt ist bekannt, da\sshauptsächlichPhysiker mit REDUCE Feyman-Graphen oder Probleme der Quantenmechanikbearbeiteten. Daneben standen Textverarbeitung, mathematische Textaufgaben und Spiele.

Schon 1967 hatte man Zugang zu IBM/360-Maschinen und beschaffte dazu das STANFORD LISP/360. Das seit 1968 von Hearn vertriebene REDUCE wurdeebenfalls besorgt. Doch LISP wurde nicht nur verwendet; man machte sich Gedanken über Testung und Verwaltung von LISP-Programmen [BA68].

Die Universität in Kiel übernahm mit der EL-X8 1968 das LISP-System aus der Niederlanden [KAL75]. InKiel wurde an diesem System sehr viel Arbeit geleistet: Es wurde an die speziellen Gegebenheiten angepaßt und beträchtlich erweitert. Dabei ist es etwas kurios, wenn Jürgensen erzählt, da\ssvor der Inbetriebnahme des {\sc vander Mey}schen Systems mit Deutschs pdp-1-LISP experimentiert wurde.Jürgensen schrieb einen pdp-1-Simulator und arbeitete so das originaleProgramm ab [DEU64].

Alle diese Arbeiten standen unter der Leitung von H.Jürgensen, der nichtnur die Arbeiten von F.Simon und H.Kalhoff betreute, sondern selbstunter anderem die erste Nutzerdokumentation verfaßte [JUE70]. Durch Simonwurde eine ``automatische Sekundärspeicherorganisation zur Speicherung von S-Expressions und kompilierten Funktionen'' aufgebaut [SIMO70]. Kalhoff istder Autor des Compilers für das X8-LISP [KAL72].

Etwa 1970 begann H.Melenk mit einer Implementierung von LISP1.5 für denTR4 in Marburg. Dieses System ist stark an STANFORD LISP/360 bzw. {\sc van der Mey}s pdp-8-LISP angelehnt, so da\ssman das Vorhandensein dieserImplementation noch für 1970 annehmen darf. Etwa 1972 wurde ein Manual erarbeitet [MEL72]. MR-LISP, wie Melenk sein System nannte [LUE73], sollte auch rechtgroße Programme verarbeiten können, obwohl der TR4 nur 18K bietet. Deshalb wurde ein spezieller Compiler entwickelt, der eine lineare Folge von Pseudoinstruktionen erzeugt und diese auf einen externen Speicher ausgibt. Für diese übersetzten Funktionen wurde ein Seitenspeicher entwickelt, der softwaremäßig verwaltet wird. Ein spezieller Interpreter für Pseudobefehle arbeitet die geladenen Funktionen ab [LUE73].

Etwa 1972 wechselte Melenk zum GRZ für die Wissenschaft in Berlin (West).Dort begann er gemeinsam mit R.Roitzsch eine Implementation für den TR440.Man versuchte, ein LISP-System zu entwickelt, das besonders gut für interaktives Arbeiten an Konsolen und Sichtgeräten geeignet ist.

Deshalb wurde spezielles Augenmerk auf Fehlermeldungen und Testhilfen gelegt [MEL73]. Auch dieses System verfügte über einem Compiler in derselben Weisewie sein Vorgänger auf dem TR4.

Da das System weiterhin gepflegt wurde, konnten die Verbesserungen 1975 in einer Neuauflage des Manuals zusammengefaßt werden [ROI75]. Es handelt sichim einzelnen um erweiterte Arithmetik, neue Ein- und Ausgabefunktionen und verbesserte Systemteile (schnelleren Interpreter und Compiler, Demand-Paging-Speicherverwaltung) Dieses Spektrum deutet auf das Hauptanwendungsgebiet des Systems, die Formelmanipulation, hin. In G.Görz'Aufstellung der ``LISP-Systeme in der BRD'' [GOE76] wird dieses System alsB\&LISP bezeichnet.

Diese Aufstellung zeigt auch die große Anzahl ausländischer Systeme, die 1976 in der Bundesrepublik Deutschland genutzt wurden. Dies waren neben den bereits erwähnten: STANFORD LISP/360 ( hauptsächlich in Verbindung mit dem Formelmanipulationssystem REDUCE), UNIVAC LISP (S.234), STANFORD LISP1.6 (S.222), UT-LISP (S.232), CDC3300-LISP (S.), LISP F1 (S.245), LISP F2 (S.246) und schließlich LISP1.6 für die B-6700 (S.266).

Seit 1973 ist ein sprunghaft gestiegenes Interesse an LISP deutlich spürbar. In Kiel, Hamburg, Bonn, Mannheim, Karlsruhe, Stuttgart, Nürnberg-Erlangen und München entstanden Forschungsgruppen für Künstliche Intelligenz. Während man sich in Kiel, Hamburg, Mannheim und Karlsruhe mit vorhandenen Systemen begnügte bzw. bessere Systeme zu erhalten versuchte, wurden in den anderen Städten neue Systeme aufgebaut. Im Zuge von Diplomarbeiten erstellten M.Leppert in München [LEP74], R.Woitok in Erlangen [WOI75] -- beide aufdem TR440 -- Systeme etwa in der Größenordnung von LISP1.5. In Regensburg wurde zur gleichen Zeit ein LISP1.5 für die Siemens 4404/45 (BS 1000) entwickelt.

In Stuttgart schließlich begann eine Gruppe um H.J.Laubsch, MacLISP aufder TR440 zu implementieren. Dieses System dürfte 1975 lauffähig gewesen sein; ein Manual [LAU76] wurde 1976 produziert. Offensichtlich als Untermengedes MacLISP vom MIT konzipiert [MOO74], enthielt MacLISP im März 1976 schon200 Grundfunktionen. Eingeschlossen sind Basisfunktionen zur graphischen Ausgabe auf Bildschirmen sowie (in LISP programmierte) Programmpakete zum Edieren, Tracen, Prettyprinten und sonstige Testhilfen.

Im Laufe des Jahres 1976 kamen eindimensionale Felder (einschließlich OBARRAY-Felder zum Auswechseln von READ-Umgebungen) und einige neueFunktionen hinzu. Interessanteste Änderungen sind dabei die drei Funktionen FUNCTION, CLOSURE und EVALFRAME.

FUNCTION liefert einen FUNARG-Ausdruck, der nur für tiefereVerschachtelungen brauchbar ist. Das betreffende funktionale Argument kann jedoch nicht als Wert nach außen gegeben werden. CLOSURE dagegen erzeugt einenechten FUNARG-Ausdruck. Es entspricht der von Sandewall vorgeschlagenenLösung des FUNARG-Problems [SAN70], indem eine Liste von freien Variablenanzugeben ist, für die die Definitionsumgebung mitgegeben soll. Für diese Variablen sind auch Zuweisungen möglich, so da\sseine Art Koroutinenkonzeptverwirklicht werden kann.

EVALFRAME macht alle dynamisch höheren Formen von EVAL samt derenUmgebungen zugänglich. Dadurch lassen sich komplexe Kontrollstrukturen implementieren. Allerdings baut der normale Interpreter diese Umgebungen nicht auf. Dazu mu\ssein besonderer Modus eingeschaltet werden. EVALFRAMEgibt als Werte eine Liste von drei Elementen, wobei das erste ein Kellerspeicherzeiger ist, das zweite die zugehörige Form, um das dritte ein Zeiger in der Umgebung. Auf diese Werte kann man sich etwa mit FRETURNbeziehen, das sein 2. Argument in der durch den Kellerspeicherzeiger (1. Argument) spezifizierten Umgebung auswertet und dann dorthin zurückspringt [LAU77].

Aus der Zeit um 1978 kann noch die Entwicklung eines LISP-Systemes für die Interdata M85 bzw. 7/32 in Kaiserslautern berichtet werden.

Die wichtigste Entwicklung um 1975-77 in der Bundesrepublik war aber wohl doch die Übernahme von InterLISP durch Siemens. Dieser Vorgang wurde wesentlich durch das Institut für Deutsche Sprache in Mannheim ausgelöst. Im Zusammenhang mit dem Projekt ``Linguistische Datenverarbeitung'' bemühte man sich um verschiedene LISP-Systeme. So beschaffte man das MTS-LISP aus Ann Arbor (S.231), im Februar 1974 dann LISP F2 aus Uppsala. Dieses wurde am Institut für Informationsverarbeitung in Technik und Biologie (IITB) in Karlsruhe implementiert. Aus diesem System wurde in der Bonner Zweigstelle die Version LISP FINT entwickelt, die gewissermaßen zwischen F2- und F3-Version (S.246) steht und eine Art InterLISP ohne Testhilfen darstellen sollte.

Doch bald kam auf die Idee, das gesamte System zu übernehmen. Urmi weiltein Mannheim und erklärte Details des Systems. Da das System einen Preis von 40 000 Kronen kostete, kam man auf die Idee, Siemens am Kauf und an der Übernahme für die Siemens 4004.151 zu interessieren. Dies gelang, und gemeinsam mit den Partnern aus Uppsala ging man daran, InterLISP in das Betriebsystem BS2000 überzuführen. Nachdem die Anfangschwierigkeiten überwunden waren, konnte Ende 1974/Anfang 1975 die erste Version den Benutzern übergeben werden.

An diesen Arbeiten beteiligt waren {\sc T.Krumnack, T.Christaller, C.Schwarz, D.Kolb,} sowie Scott, Sievert, Vokand und Ritzer. Anfang 1975verfaßte B.Epp das erste Programmierhandbuch [EP77]. Siemens-InterLISP[GU78a], wie das System seitdem genannt wird, ist bis 1978 überarbeitetworden und liegt inzwischen in der Version 3 vor [GU78b]. Es entspricht demZustand des InterLISP für die pdp-10 von 1972.

Ähnlich wie im InterLISP360/370 wird das System in zwei wesentliche Komponenten aufgeteilt: Das Grundsystem enthält alle LISP-Primitivfunktionen sowie alle betriebssystemabhängigen Routinen zur Speicher- und Betriebsmittelverwaltung. Dieses Grundsystem ist in der Assemblersprache unter Verwendung des SPL-Laufzeitsystems implementiert. DasEntwicklungssystem definiert den größten Teil des Sprachvorrats von Siemens-InterLISP. Es enthält Funktionspakete wie Compiler, Editor, BREAK-Paket, ADVISE und TRACE usw. und ist in LISP geschrieben. DerAnteil des Grundsystems am gesamten Siemens-InterLISP-System beträgt weniger als 10\%.

Die Pläne im Jahre 1978 betrafen sowohl Teile des Grundsystems als auch die Erweiterung des Entwicklungssystems. Das Grundsystem sollte schneller ... mittels Integration von Wortzellen. Der Garbage Collector sollte zu einem parallelen Echtzeit-Garbage Collector weiterentwickelt werden. Die Verwendung von Direkzugriffsdateien und indexsequentiellen Dateien war als weitere Verbesserung gedacht.

Das Erweiterungssystem sollte DWIM aufnehmen. Der Compiler sollteverbessert werden; kurioserweise erwartete man die Generierung ``optimaleren Codes'' ([GU78b], S. 17). Man hatte vor, auch den Blockcompiler zuübernehmen. Schließlich knüpfte man an das LAP die Hoffnung, zur Simulationvon Maschinen (``künftige Architektur neuartiger hardware'') verwendet werden zu können. Dazu sollte ein LAP-Interpreter entwickelt werden.

 

DDR

In der DDR begann die Forschung auf dem Gebiet der Künstlichen Intelligenz etwa 1969, kurz nach Gründung des Kombinats Robotron. Die kleine Arbeitsgruppe unter der Leitung E.Lehmanns war in einenGesamtzusammenhang ``Automatisierung der Programmierung'' gestellt worden. Ziemlich bald war klar, da\ssdas Basissystem für die erstrebten praktischenArbeiten nur LISP sein konnte.

1970 begann P.String mit dem Entwurf eines Interpreters. Diese Arbeit warnicht einfach, weil die gesamte Information über LISP in dem bekannten Buch von Berkeley und Bobrow [BB64] bestand. Andere Information schien nichterhältlich.

Als Mitte 1970 ein Rechner zur Verfügung stand, begann H.Stoyanunabhängig von dem Stringschen Ansatz mit der Auswertung des Artikels vonDeutsch über das pdp-1-lisp[DEU65]. Der erste Interpreter war praktisch eineUmsetzung des Systems von Deutsch auf die IBM-kompatiblen ESER-Anlagen. Trotz äußerst knapper\footnote{2 Stunden pro Woche} Rechenzeit lief ein sehr eingeschränktes System noch 1970; LISP1.5 (ohne Felder und Gleitkommaarithmetik) wurde etwa Mitte 1971 erreicht.

Der Autor war zu dieser Zeit alles andere als ein LISP-Freund und stand Erweiterungen nicht mehr allzu bereitwillig gegenüber. Lehmann und andereMitarbeiter benötigten für ihre Arbeiten jedoch ein leistungsfähigeres System. So begann String mit der Umsetzung des Q-32 Compilers [SAU64c] fürESER-Rechner, während der Autor mit den Mitarbeiterinnen I. Köhler und {\sc S.Kühnel} das LISP-System nach und nach an das LISP1.6-Niveau heranführte. Als Ende 1971 erste Compiliertests vielversprechend aussahen, plante er das Run-Time-System für den Compiler und schlug eine Handcompilierung des bis dahin in LISP geschriebenen Compilers vor. Dies wurde durchgeführt, und das resultierende Programm zeichnete sich immer durch enorme Geschwindigkeit aus.

Anfang 1972 war das LISP1.6-System vollendet. Es umfaßte damals allerdings keine Felder, enthielt nur Ganzzahlarithmetik und erlaubte keinen Wechsel der Ein- und Ausgabeströme. Dagegen gab es eine Direktzugriffsmöglichkeit, die in den P-Listen die externen Adressen der ausgelagerten Eigenschaften enthielt und bei einer GET-Operation diese automatisch eingelagerte. An diese Dateiwar auch der Compiler angeschlossen, der die compilierten Programme im Maschinenformat auslagerte (zuzüglich einer Liste von Literalen im externen LISP-Format). Bei der Abarbeitung wurde die Funktionen automatisch von den Plattendatei geladen und nach Vorrangprinzipien, die der Nutzer festlegen konnte, verwaltet.

Anfang 1973 wurde die Arbeit auf dem Gebiet der Künstlichen Intelligenz gestoppt. Nur eine kleine Gruppe konnte sich weiter mit Frage-Antwort-Systemen beschäftigten.

1974 wechselte der Autor zur Technischen Universität Dresden. Durch eine Reihe von Zufällen entstand eine Situation, in der eine Weiterentwicklung bzw. Neuaufnahme der LISP-Arbeiten als günstig erschien. Begonnen wurde mit einer völligen Neustrukturierung und Überarbeitung des Systems. Dadurch wurden zukünftige Änderungen erleichtert, das System wurde überschaubar und modular. Ein Geschwindigkeitstest (vgl. S.?) lieferte für eine Liste von 20-Elementen in diesem System eine Zeit von 1460 ms und für eine Liste mit 40 Elementen 62400 ms.

Anfang 1975 wurde ein neuer Beschleunigungsansatz begonnen. Bis dahin waren die Wertzellen (SPECIAL-Zellen) gewöhnliche Eigenschaften beimzugeordneten SPECIAL-Indikator. Dies wurde geändert, so da\ssjedes Atom imAtomkopf den Wert trug. Gleichzeitig wurden die Typbeschreibungen aus der Datenzellen in den Zeiger auf die Datenzellen verschoben. Nun erreichte das System für denselben Test für die Liste aus 20-Elementen eine Zeit von 1000 ms und für die mit 40-Elementen 3620 ms.

Gemeinsam mit den Studentinnen Steinborn und Neuhaus wurde dieParameterübermittlung bis zum Sommer 1975 völlig neu erarbeitet. Bis dahin war eine Liste ausgewerteter Argumente gebildet worden, in die das jeweils nächste am Ende eingefügt wurde. Statt dessen wurden nun die ausgewerteten Argumente auch im Interpreterregime genauso wie für compilierte Funktionen im Kellerspeicher angeordnet. Gleichzeitig wurden Funktionen wie LISP undTIMES von FSUBR- zu LSUBR-Funktionen umgetauft. Für Zwecke derFehlerüberwachung wurden die Argumente gezählt und bei Nichtübereinstimmung der gelieferten mit den geforderten Argumentzahlen Fehler gemeldet (im Fall der LSUBR-Funktionen wurden nur die aktuellen Argumente gezählt, umEinheitlichkeit in der zentralen Routine EVLIS zu haben). Die Messungen ergaben nun für die kürzere Liste (20 Elemente) 720 ms und für die längere Liste (40 Elemente) 2620 ms.

Etwa im Sommer 1975 erhielt der Autor zum erstenmal ein Assemblerlisting des STANFORD LISP. Vergleiche der Code-Stücken ergaben manche Vorteile des STANFORD LISP/360 und andere Vorteile des DOS/ES LISP1.6. Die Unterschiede wurden sorgfältig ausgewertet und die betroffenen Systemteile umgeschrieben. Dies waren jedoch keine zentrale Verarbeitungsprogramme, sondern z.B. das Garbage Collection (die Idee, im CONS keinen Test auf das Ende derFrei-Speicherliste zu machen, sondern einen Programmfehler zu erzeigen, waren bereits Anfang 1975 aus den Unterlagen des Waterloo LISP/360 [BOL68]entnommen worden).

Anfang 1976 erfuhr der Autor von den Effizienzvergleichen T.Kurokawas[KUR76c]. Um zu einem ``ehrenhaften'' Vergleichswert zu gelangen (auch dieübrigen Messungen sind erst damals gemacht worden), sind noch einmal sorgfältig alle Bremsen gesucht und entfernt worden. Das System führte nun keinerlei CONS-Operationen bei der Interpretation mehr aus, berechnete diemaximale Anzahl erforderlicher Kellerspeicherplätze an der Stelle, an der feststeht, da\ssüberhaupt gekellert werden muß, und kellert von da an ohneÜberprüfung usw. Durch kleinliche Befehlsaufrechnung und -ersetzung konnte schließlich für die 20-Elemente-Liste 580 ms und für die 40-Elemente-Liste 2120 ms erreicht werden. Diese Werte erwiesen sich als nicht unterschreitbar.

Durch die Einführung von Meßmitteln gemä\ssdem InterLISP-BREAK-DOWN, diedie Verarbeitung so wenig wie möglich beeinflussen sollten, mußte Anfang 1978 eine unbedeutende Laufzeitverschlechterung auf 680 bzw. 2540 ms in Kauf genommen werden. Der Compiler liefert Programme, die für dieselben Beispiele 98 bzw. 340 ms benötigen.

Anfang 1977 wurden Experimente für ein Software-Paging des Listenspeichers gemeinsam mit S.Kanew [KAN78] bezüglich dessen Modell des Software-Pagersfür das DOS/ES durchgeführt. Das sorgfältig auf minimale Benutzung des Listenspeichers zugeschnittene System benötigte für die gleichen Beispiele wie oben 2520 ms. bzw. 9580ms\footnote {Zum Vergleich: LISP1.9 erreicht auf TOSBAC-5600 die Zeiten 263 ms, 946 ms. UT-LISP erreicht auf CDC6600 für die kürzere Liste 389 ms; STANFORD LISP 360 auf IBM/360.67 erreicht 960 ms bzw. 3580 ms; STANFORD LISP1.6 auf DEC-20 erreicht 568 bzw. 2079 ms; LISP3300 auf CDC3300 erreicht in 40 K 4751 ms bzw. 20029 ms; UT-LISP auf CYBER-172 erreicht in 64 K 894 ms bzw. 5728 ms.}.

Bis 1979 ist das DOS/ES-LISP1.6 noch wesentlich gewachsen. Es enthielt Zeichenketten und Felder beliebig vieler Dimensionen (wie übrigens auch die Argumentzahl der Funktionen unbegrenzt gewesen ist)\footnote {LISP 1.5 begrenzte auf 20 Argumente, MacLISP begrenzt auf 5 Argumente, STANFORD LISP/360 begrenzt auf 22 Argumente.}, über 400 Funktionen und einen insgesamt international durchaus vergleichbaren Zuschnitt [STO78].

 

Polen

Auf der Konferenz über Symbolmanipulationssprachen und -techniken vom 5.-7. September 1966 in Pisa hatte S.Waligorski die Zeichenkettenverarbeitungssprache LOGOL vorgestellt. Er wurde dort jedoch mit einer derartigen Anzahl von Implementationen und Anwendungen von LISP konfrontiert, konnte er sich von der Qualität überzeugen und mit Implementatoren sprechen, da\sser zurückkehrte mit der Absicht, LISP zu implementieren.

Anfang 1967 erschien der Artikel von Cohens über die Einbettung von LISPin ALGOL [CO67a], und Waligorski beschloß, diesen Weg ebenfalls zu gehen.Er verfügte mit dem GIER-ALGOL über ein berühmtes effizientes System [NAU67]. Gemeinsam mit den Studenten H.Zelman, J.Zamorski und {\sc M.Pluciak} wurde bis etwa 1968 ein LISP-System in die Version ALGOL4 eingebettet. Die eigentliche Programmier- und Testarbeit scheint dabei Zelman geleistet zuhaben [Z69]. Dieses System wurde für die Lehre an der Warschauer Universitätverwendet [WALI70].

Wie in Cohens System waren die Grundfunktionen als ALGOL-Prozedurenverwirklicht. Die Listen wurden in einem Feld dargestellt; die Indizes als Zeiger benutzt. Der Listenspeicher erreichte Ausmaße zwischen 2 und 4K.

Durch die Begeisterung Waligorskis angesteckt und durch {\sc Z.Pawlak} ermutigt, begannen dann 1968 J.Loska und seine Helferin {\scB.Zochowska} mit einer LISP1.5-Implementation auf der Odra1204. Dieser Rechner erreicht etwa 200 000 Operationen pro Sekunde und bot 64K Hauptspeicher. Das System, das 1970 verwendbar war, entsprach recht genau dem originalen LISP1.5 [MCC62c]. Zusätzlich war der Zugriff über Displaysgewährleistet.

Das System sollte für Forschungen auf dem Gebiet des Schaltkreisentwurfs benutzt werden bzw. für theoretische Arbeiten über Datenstrukturen. Allerdings scheint es keine große Nutzergemeinde gegeben zu haben.

Dennoch starteten Loska und Zochowska 1974 ein neues Projekt:diesmal wollte man STANFORD LISP1.6 auf der Odra 1304 bzw. 1305 implementieren.

1975 umfaßte dieses System nahezu alles, was im STANFORD LISP1.6 enthalten ist. Ausnahmen waren: die Funktionen EXPLODE, BOOLE und DM (d.h. keine Makros) und die Funktionen zum Austausch von Ein- und Ausgabekanälen. Eine weitere Einschränkung bestand in der Arithmetik, denn man hatte nur Integers erlaubt.

Da an der System weitergearbeitet wurde, ist es etwa 1976 komplett fertig geworden.

Für die Formelmanipulation entwickelte Bartnik etwa 1974 ein LISP-Systemfür den KAR65 an der Warschauer Universität (Sektion Physik).

Eine größere Gruppe, die sich der LISP-Implementation und -Anwendung verschrieben hat, wurde 1973 in Pozn\'an (Posen) gegründet. Man begann mit der Implementation von LISP für den Minicomputer K-202. Obwohl das System als LISP1.5 firmierte [BER73], enthielt es doch Funktionen wie READCH, RATOM,erlaubte es den Wechsel der Eingabekanäle usw. Auch ein Compiler war geschrieben worden. 1974 wandte sich M.Berlog, B.Begier, J.Kniat und M.Stroinski dem Rechner Odra 1204 zu, für die ein in etwa kompatibles System erstellt wurde [BER74].

 

UdSSR

Obwohl man in der UdSSR LISP schon vor 1963 zur Kenntnis genommen hatte [FEI61], begann die eigentliche Aufnahme doch erst nach 1967. Grund fürdiesen späten Start kann man einerseits in der mangelnden Popularität von Rechneranwendungen für nichtnumerische Zwecke sehen. Zweitens aber hatte Turtschin [TUR68, 77] ein vorzügliches, der BESM-6 angepaßtes System zurnichtnumerischen Informationsverarbeitung namens REFAL entwikkelt. Noch lange konnte man in der UdSSR hören, dieses System sei viel besser und günstiger als LISP.

Die Einführung von LISP in die UdSSR ereignete sich, als S. S. Lawrow 1967mit Berkeley bekannt wurde. Berkeley war zu dieser Zeit einausgesprochener LISP-Fan. Er steckte Lawrow mit seiner Begeisterung an, undbeide programmierten in der Zeit von Berkeleys Moskau-Aufenthalt(vermutlicher Anla\sswar eine internationale Konferenz) 1967 einen erstenInterpreter bzw. Teile für ein solches Programm.

Auf Initiative von Berkeley wurde Lawrow dann in die USA eingeladen, undzwar offiziell als Gast von Berkeleys eigener Firma. Hier konnte Lawrowdas MIT besuchen, sich über LISP informieren und über die Implementation Auskünfte erhalten.

1968, nach Lawrows Rückkehr nach Moskau, begann die eigentlicheProgrammierarbeit am Rechenzentrum der Akademie in Moskau. Das System lief dann in seiner ersten Version noch 1968; stabil war es vermutlich seit Anfang 1969 [LAW69]. Mitarbeiter von Lawrow noch während der Implementation wurdeder Georgier G.S.Silagadse. Unter Lawrows Leitung überwachte er dieKorrektheit des Systems und begann mit den Arbeiten an seinem Compiler.

Etwa 1971 legte Silagadse eine Doktorarbeit vor, deren Gegenstand derLISP-Compiler war [SIL71a]. Er übernahm die Pflege des BESM-6-LISP in eigenerRegie nach Lawrows Wechsel zur Universität nach Leningrad.

Als Silagadse etwa 1973 nach Tbilissi zurückkehrte, wurde W.M.Jufa derHalter des LISP-Systems. Unter seiner Leitung wurden 1973 eine Reihe von neuen Funktionen bereitgestellt, das System in das von dem Mitarbeitern des Rechenzentrums der Akademie selbst entwickelt Time-Sharing-System PULT integriert [BRI72]. Die Begrenzung des Nutzerraums auf 32K BESM-6-Worte(zu 48Bit) waren jedoch immer eine ernste Grenze für die Komplexität der möglichen Anwendungen. Kein Wunder, wenn man lange Zeit LISP nicht als zukünftige Basis der Forschung ansah. Das Erscheinen der ESER-Rechner mit ihren recht großen Hauptspeichern hat möglicherweise die Situation geändert.

Lawrow setzte seine Arbeit in Leningrad fort. Das Basissytem dafür wurdeein 1973 implementiertes LISP1.5-System auf einer Odra 1204.

Seit etwa 1974--75, vielleicht maßgeblich stimuliert durch den 4. Internationalen Kongre\ssfür Künstliche Intelligenz in Tbilissi [AD75], isteine wesentlich lebhaftere Tätigkeit auf dem Gebiet der Künstlichen Intelligenz in der UdSSR in Gang gekommen. Verbunden damit war die Entwicklung mehrerer LISP-Systeme.

BESM-6-LISP, das bis 1973 das einzige und weitverbreitete System war, hat bis heute eine Reihe von Konkurrenten bekommen: ?.Pantelejew entwickelte 1975auf der ICL-4 ein in jeder Hinsicht (Befehl für Befehl) kompatibles System mit BESM-6-LISP. ?.Gitman, ?.Feinman und einige Kollegen begannen im selbenJahr mit der Implementation für ESER-Rechner in Wladiwostok. Sie setzten diese Arbeit in Leningrad bei Lawrow fort und entwickelten eininteressantes, schnelles System, das im OS/MVT läuft und in vieler Hinsicht LISP1.6 entspricht.

In Moskau wurde 1975 am MEI das System LISP/EC entwickelt. Dieses System arbeitet im DOS. Es entspricht weder LISP1.5 noch anderen Vorbildern und enthält sowohl übliche Funktionen als auch singuläre Entscheidungen [BAI77].Erwähnenswert mag die direkte Programmierbarkeit der Kopplung von LISP und PL/I-Programmen sein, die über die CALL-Funktion erledigt wird. AnDatenstrukturen werden auch Zeichenketten und Felder geboten. 1979 wurde LISP/EC ins OS umgesetzt.

Neben den eigenen Entwicklungen sind schon seit geraumer Zeit einige ausländische LISP-Systeme in der UdSSR verfügbar. Dies ist gewi\ssfür STANFORDLISP/360, das über Dubna Eingang fand, für UT-LISP, das mindestens auf der CDC6600 in Dubna läuft, sowie für das DOS/ES LISP1.6, das aus der DDR Ende 1976 nach Odessa importiert wurde [GER77]. Als McCarthy 1968 Nowosibirsk besuchte,begann er mit der Implementation eines LISP-Systems für die BESM 6 unter Verwendung der Systemprogrammiersprache ALPHA. Dieses System wurde später mit russischen Funktionsnamen weitergeführt und ist erst 1975--76 von {\sc L.Gorodnjaja} vollendet worden.

 

Ungarn

In Ungarn begann sich eine Gruppe von Mitarbeitern des SZTTAKI-Institutes unter der Leitung von I.Bach 1972 mit der LISP-Implementation zu beschäftigen.Die Gruppe, zu der auch E.Farkas, M.Naszodi und J.Fabou gehörten, warvor allem vom äußeren Bild der Sprache fasziniert: Die völlige Verschiedenheit von anderen Programmiersprachen und die schöne Form fesselten diese Wissenschaftler, die sich zwischen 1970 und 1971 etwas mit Künstlicher Intelligenz beschäftigt hatten.

Man hatte Kenntnis von Deutschs pdp-1-LISP, das als Vorbild diente, und vomLISP F1 aus Uppsala.

Bis 1973 wurde ein Interpreter implementiert, der etwa 40 Funktionen umfaßte und in einem einfachen Time-Sharing-System auf dem R10, einer ungarischen Entwicklung, lief. Der Listenspeicher faßte etwa 4K.

1974 begann F.Potari am TKI, ebenfalls in Budapest, mit der Implementationeines größeren Systms für denselben Rechner. Das System sollte für den Entwurf von Schaltkreisen verwendet werden. Potari programmierte über 180Funktionen, entwickelte ein System für Datei-Verarbeitung und versuchte, ein regel-basiertes Subsystem in das LISP-System zu integrieren.

Das System erlaubte nur ganze Zahlen. Für die Notation der Atomsymbole waren 72 Zeichen lange Namen erlaubt, darüber hinaus konnte jedes Zeichen als Character Atom auftreten, wenn es durch " eröffnet wurde.Eindimensionale Felder, Vectors genannt, und zugeordnete Grundoperationenwaren ebenfalls vorhanden.

Für die regel-orientierte Programmierung hatte Potari den LAMMAT-Ausdruck eingeführt:Dieser hatte die Form {\tt(LAMMAT modvarlist} (form rulelist)). Statt formkonnte in gewissen Fällen auch nur ein Funktionsnamen stehen. Die Regeln hatten die Form: (model predicate value). Die Musterfunktionen werdendurch EVAL als EXPR-Funktionen werden vier Argumente übergeben: dieModvar-Liste (Mustervariablen aus der Rule-Liste), die Rule-Liste, die Argumente (als Liste) und die aktuelle A-Liste.

Die implementierte Funktion EVMATCH arbeitet Regel für Regel aus derRule-Liste in folgender Weise ab: Zuerst wird versucht, ob die Argumentliste auf das Muster (model) paßt. Ist das der Fall, dann werden dieMustervariablen gebunden, eine durch diese Bindungen erweiterte A-Liste hergestellt und predicate wird ausgewertet. Liefert diese Auswertung T,dann wird value in derselben Bindungsumgebung ausgewertet. Damit ist dann derGesamtwert des LAMMAT-Ausdrucks bestimmt. Wenn entweder der Mustervergleichoder die Prädikatauswertung versagt, wird zur nächsten Regel übergegangen.

An das ganze System war ein externer Bibliotheksspeicher angeschlossen, der automatisch oder gerichtet benutzt werden konnte. Wurden alle Standardfunktionen geladen, so blieb lediglich ein Platz von 2000 Listenzellen übrig. Mit Hilfe eines Swappers zu der Festkopfplatte konnten auch in dieser Umgebung große Programme interpretiert werden. Jedoch 64K freier Speicher seien für vernünftige Anwendungen erforderlich, konstatierte Potari in seiner Beschreibung [POT75].

Nachdem Potari 1976 noch einen Compiler entwickelt hatte, mußte er seinSystem aufgeben. Seine Nutzer waren zum Schlu\ssgekommen, da\ssListen eineschlechte Repräsentation seien und das System überhaupt zu uneffizient.

1977 begann am Institut SZAMKI P.Szöves eine LISP-Implementation für eineHonneywell H80. Er wollte ein mit InterLISP kompatibles System erstellen.

 

Italien

In Italien ist LISP seit mindestens 1966 in Benutzung. So erwähnt ([CAM66],S.63) das Laboratori Nazionali di Frascati in Frascati bei Rom, wo offenbar Physiker LISP für Zwecke der Formelmanipulation einsetzten. Kurze Zeit später implementierte A.Miola mit Freunden ({\sc C.Böhm, G.Ausiello, H.Moncayo, L.P.Deutsch}) LISP auf einem Olivetti-Prototyp CINAC, die sein Institut (LAC-CNR in Rom) geschenkt bekommen hatte. Die Arbeit war höchst kompliziert, weil praktisch nicht ein einziges Programm auf der Maschine lief. Man mußte im Maschinencode beginnen.

Seit etwa 1972 wird in Pisa sowohl an der Universität als auch im Institut für Informationsverarbeitung an Problemen der Künstlichen Intelligenz gearbeitet. Während man vorher in Italien mit importierten Systemen ausgekommen war, glaubte man, nun ein eigenes Verarbeitungssystem für LISP entwickeln zu müssen.

Das erste LISP-System wurde im Laufe des Jahres 1972 für die IBM/360 aufgebaut [ASI72]. Man betrachtete es mehr als Basissystem für PLANNER-oder CONNIVER-ähnliche Erweiterungen. In dieser Richtung wurden 1973 einigeAnsätze gemacht [MON73a,MON73b]. Vermutlich sind zum Experimentieren auch Teiledieser Systeme implementiert worden. In Pisa hat man dafür regelmäßig höhere Programmiersprachen verwendet, wie PL/I bzw. FORTRAN.

Alle diese Arbeiten gipfelten schließlich 1975 in der Erarbeitung und Implementierung von MAGMA-LISP [MON75]. Mit diesem System wollte man eine``Maschinensprache für die Künstliche Intelligenz'' bieten, die für Implementationszwecke benuztbar ist und diese alle Basisoperationen bereitstellt. Grundbegriff in MAGMA-LISP ist der Context, eineInformationstruktur, die sowohl die Daten bzw. Fakten einer bestimmten Situation des Rechenprozesses enthält (d.h. den Zustand der Datenbasis) als auch die Information, die für den dynamischen Ablauf wichtig ist, d.h. die Beziehungen zu umfassenden Prozessen und die Rückkehrpunkte.

Die Contexte sind untereinander baumartig verknüpft. Der Nutzer kann diese Baumstruktur manipulieren bzw. zu einem beliebigen Zeitpunkt der Verarbeitung erforschen. Mit Hilfe der Funktion APPLY kann man Prozesse innerhalbgewisser Contexte starten. Bei diesem Vorgehen werden gleichzeitig Anteile der in dem ursprünglichen Context vorhandenen Information in den neuen Context übergeben. Austausch von Contextbestandteilen kann auch direkt über die Funktionen GET und PUT veranlaßt werden.

Ende 1975 war MAGMA-LISP aktionsfähig [ASI75]. Es war in FORTRANimplementiert worden und lief auf der IBM/370.168 im Betriebssystem VM/370-CMS. Einige Jahre wurde es für Ausbildung und Forschung in Pisa verwendet.

 

Dänemark

In Dänemark scheint LISP lange Zeit unbekannt geblieben zu sein. Vielleicht benutzte man auf verschiedenen Anlagen fremde Systeme. Ein Indiz für die Nicht-Benutzung ist, da\ssauf der CDC6400 der Universität von Aarhus noch 1975kein LISP-System verfügbar war.

Im Frühjahr 1975 wurde im Rahmen einer Vorlesung über ``Programmiersprachen höheren Niveaus'' mit einer LISP-Implementation begonnen. 25 Studenten unter der Leitung von N.Derrett und M.Solomon programmierten elf kleineModuln in BCPL und erstellten so einen Interpreter. Man hatte sich entschieden, kein PROG aufzunehmen und einfachere Zugriffsbereichsregeln alsin LISP zu benutzen. Der Dialekt wurde ``Lisbet'' genannt. Dieselbe Aktion wurde im Frühjahr 1976 wiederholt. 1976 schließlich formte einer der beiden Leiter das Programm so um, da\sses wesentlich maschienenunabhängig wurde. Es kann nunauf jedem Rechner laufen, der eine Wortlänge von 16 Bits und mehr hat, sowie über einen BCPL-Compiler verfügt [DERR77].

 

CSSR

Die LISP-Aktivitäten in der CSSR begannen nach einem Besuch {\sc Konicek}s von der Prager Technischen Hochschule in Stanford etwa 1970. {\sc K.Müller} und J.Kolar begannen Ende 1971 für die Tesla 200 einLISP-System zu entwickeln, das sich völlig an die Beschreibung des LISP1.5 [MCC62c] hielt. Außer dem Compiler und den Feldern wurden alle Elemente getreuimplementiert. Dieses System lief etwa 1972 [KOL74] und wird seitdem zur Lehrebenutzt.

Ein anderes, kleineres System wurde im Rahmen einer Diplomarbeit am Institut VUMS implementiert.

Inzwischen ist in der CSSR auch STANFORD LISP/360 zusammen mit dem Formelmanipulationssystem REDUCE verfügbar.

 

Belgien

In Belgien ist LISP, wie auch in anderen westeuropäischen Ländern, seit Anfang der sechziger Jahre bekannt. Sicher wurden Systeme auf der IBM7090 genutzt. Eine heimische Implementation wurde von P.L.Wodon 1967 amMBLE-Institut in Brüssel erstellt [WOD66]. Die Publikation desersten LISP-Lehrbuchs in französischer Sprache durch D.Ribbens [RIB69],heute Universität von Liege, deutet ebenfalls auf LISP-Aktivitäten hin: Auf sein 1967 am Facult\'e Polytechnique in Mons programmiertes System für den Bull Gamma M40 [RIB67].

 

Schweiz

In der Schweiz begann mit der Gründung des Instituts für das Studium der Semantik und des Denkens (ISSCO) in Castagnola bei Lugano energische LISP-Aktivität. Für die Arbeiten zur Analyse der natürlichen Sprachen brauchte man ein leistungsfähiges System. Da man Zugriff hatte zu einer CDC6600, übernahm man die aktuelle Version von UT-LISP (ca. 1974) Den Forschern um N.Goldman und P. Hayes genügte die Version aber nicht, undsie erdachten zahlreiche Verbesserungen [GOLM75]. Leider konnte das neueLISP-System nicht zu neuen Forschungsergebnissen inspirieren, denn das Institut mußte wegen Geldmangels Ende 1975 geschlossen werden.

An der ETH und an der Universität in Zürich ist seit etwa 1976 InterLISP360-370 verfügbar [EP77].

 

LISP in Übersee

 

Mexiko

H.McIntosh hat in Mexiko City ein weiteres LISP-Zentrum gegründet. ImRahmen der amerikanischen LISP-Geschichte war erwähnt worden, da\ssMcIntosh1963 nach Mexiko City übersiedelte. Nicht lange nach ihm kam auch L.Hawkinson dorthin.

Die Arbeiten in Mexiko wurden entweder am Centro Nationale de Calculo oder an dem Nacional Polytechnical Institucio durchgeführt. Dort war eine IBM709 verfügbar, und Hawkinson hat auf ihr etwa 1964 ein LISP1.5 Systemimplementiert.

1965 begann A.Guzman mit seinen Arbeiten für CONVERT. Dafür konnte ernach seinen Angaben das per Fernverarbeitung erreichbare Q-32-LISP in Santa Monica und zwei mexikanische LISP-Systeme verwenden. An diesen lokalen Systemen haben Hawkinson und Yates gearbeitet [GUZ67].

Das schnellere dieser beiden Systeme wurde MB-LISP genannt. Es lief ebenfalls auf der IBM709. Es sei ``ein LISP-Dialekt, der sich von LISP1.5 in einer ganzen Reihe von technischen Details unterscheide...'' Er biete ``exzellente Feld- und Gleitkommamöglichkeiten'' und sei überhaupt ``sorgfältig organisiert''[?].

Etwa zur gleichen Zeit überzeugte sich der in Mexiko arbeitende Physiker T.A.Brodyvon der Brauchbarkeit von LISP für symbolische Rechnungen für die Physik. Er entwickelte eine eigene Version für eine IBM1620, das LISPITO [BROD65].

Zwischen 1967 und 1971 ist wenig über LISP-Aktivität in Mexiko bekannt. Da\ssman jedochnicht geschlafen hat, zeigt die Implementation von LISP1.6 für den B6700-Rechner [MAG74].

Dieses System wurde 1971 durch M.Magidin und R.Segovia am Centro deInvestigacion en Mathematicas Aplicadas y en Sistemas entwickelt (bzw. an der Universität von Mexiko City). B6700-LISP ist in Burrough EXTENDED ALGOL [BURR64] programmiert. Es konnte entweder im Stapelbetrieb oder interaktivarbeiten.

Dem Nutzer trat EVALQUOTE entgegen, so da\ssPaare von S-Ausdrückenverarbeitet wurden. Der Listenspeicher war ein Feld von 64K, in dem Räume (d.h. Seiten) von je 256 Worten typenrein auf folgende Datentypen aufgeteilt waren: Listen, Atome, große Integers (kleine sind als Zeiger dargestellt), und Felder. Die LISP-Zellen waren in die 48-Bit-Worte gepackt, so da\sssowohl Car-als auch Cdr-Zeiger 22 Bits lang waren. Atome umfaßten zwei Worte für die \mbox{Wert-,} P-List- und Verarbeitungsinformation sowie weitere Worte und den dichtgepackten Bereich der Elementzeiger. Große Felder wurden zerlegt.

Das B6700 LISP enthielt 1974 etwa 140 Grundfunktionen, von denen eine ganze Reihe mehr an InterLISP als an LISP1.6 erinnerten. Für interaktive Arbeit stand ein Editor zur Verfügung.

 

Japan

In Japan können seit 1974 äußerst lebhafte LISP-Aktivitäten beobachtet werden.

Bis etwa 1967 sind keinerlei Arbeiten bekannt. Es mag sein, da\ssaufimportierten Anlagen vorher schon LISP1.5 verfügbar war. Etwa 1967 wurde in einer gemeinschaftlichen Arbeit der Universität von Tokio und der Rechnerfirma Hitachi das anscheinend erste japanische LISP-System HELP auf einer HITAC-5020 implementiert. Nähere Einzelheiten fehlen.

1968 folgte M.Nakanishi von der Keio Universität (Keio Institut ofInformation Science) mit seinem System KLISP [NAK68]. Dieses für Lehrzweckegedachte System vereinfachte LISP in verschiedener Weise. Es hatte nur einen Interpreter und etwa 120 Grundfunktionen. Der Basisrechner war eine TOSBAC-3400/30.

Einige Zeit darauf lernte Nakanishi die pdp-8-Implementation von {\sc van derMey} und van der Poel kennen. Nach Zusammenfassung der mit KLISP gemachtenErfahrungen und der Ideen aus Delft programmierte er unter Mithilfe einiger Kollegen die beiden MINILISP und KLISP-11 für die Kleinrechner HITAC-10 bzw. pdp-11 [NAK69].

Schon 1970 mu\ssso viel an Ergebnissen und Erfahrungen vorhanden gewesen sein,da\ssein Sammelband, herausgegeben von H.Ammiya, erschien [AMA70].

Noch vor 1974 entstanden die Systeme DOS/EDOS-MSO LISP1.5 (Watanabe undFutamura,Hitachi Ltd.) auf einer HITAC-8350 und TLISP Miyazaki et al.)auf TOSBAC-5600, das sich an KLISP anlehnte.

1972 begann man am Elektrotechnischen Labor der Toshiba Corporation mit der Implementation eines international vergleichbaren Systems. Man beschloß, sich an LISP1.6 zu halten. Das System sollte als erstes japanisches LISP-System sowohl Interpreter als auch Compiler besitzen, sich passend in ein Time-Sharing-System eingliedern, einigermaßen fortgeschrittene Programmierhilfen bieten und freie Arbeit mit Datenbeständen erlauben. Anfang 1973 konnte ein erstes Manual verfaßt werden. Dieses System, EPICS-LISP1.6, das im wesentlichen von T.Kurokawa konstruiert wurde, lief auf derTosbac-56000 und ersetzte TLISP.

Kurokawa arbeitete weiter und erreichte ein Jahr später einen solchenStand, da\sser glaubte, den Namen LISP1.6 nicht mehr vertreten zu können. Sowurde das Manual [KUR74] mit ``LISP1.8'' überschrieben.

Unter Verwendung von Ideen von InterLISP veränderte Kurokawa in derFolgezeit den Speicher. Insbesondere wurde die Datenstrukturdarstellung so geändert, da\sssie Zeigerkomplexe wurden, die die Verarbeitung maximalbeschleunigten [KUR76c]. Seine Ideen über ein effizienteres GarbageColection, die 1975 noch um Kellerspeicherausnutzung im Rahmen des einfachen McCarthyschen Algorithmus kreisten [KUR75], reiften zu einer Verbesserungdes Grundalgorithmus und zu einer Behandlung der Kellerspeicherüberläufe dieses Algorithmus heran [KUR76b]. Diese sorgfältige Analyse der wichtigstenTeile des Interpreters zeitigte Erfolg: Als die schwachen Punkte beseitigt waren, erreichte LISP1.9, wie es nun genannt wurde, erhebliche Laufzeitverbesserungen [KUR76c].

Um 1979 dürfte LISP1.9 von Kurokawa eines der effizientesten Systeme der Weltgewesen sein. Es ist sicher das verhältnismäßig schnellste mit konventioneller Speicherorganisation [IPSJ].

1973 hatten Sato et al. auf einem Symposium über Programmierung [SAT73]in Anlehnung an frühere Ideen von McCarthy, die in das unvollendeteM44-LISP von Wooldridge eingeflossen waren, ein neues Hash-Schema für LISPvorgeschlagen. Diese Idee wurde von Goto aufgegriffen. Anders als imHash-LISP, schlug er vor, sollten nur besondere Listenstrukturen dem Hash-Schema unterworfen werden. Sein System HLISP [GOT74a], das auf dieserIdee aufbaute, führte konzequenterweise zwei CONS-Funktionen ein: CONSund HCONS. Später trennte er die LISP Strukturen noch deutlicher von dender Hash-Verwaltung unterworfenen: Diese wurden nun ``Tupel'' und ``Menge'' genannt [GOT76].

Das erste HLISP-System lief Anfang 1974. Dieses System war neben der Speicherverwaltung auch noch mit einer Ergebnisverwaltung ausgerüstet, einer weiteren Idee E.Gotos: Er hatte bemerkt, da\ssin vielen rekursivenBerechnungen bereits ausgewertete Ausdrücke wiederholt behandelt werden. Dies gilt insbesondere für viele der Basisfälle der Rekursionen. Oft aber kommt es vor, da\ssauch komplexere Ausdrücke mehrfach berechnet werden. So kann es dennsein, da\ssein bemerkenswerter Anteil der Rechenzeit für die Ermittlungbereits bekannter Resultate verschwendet wird.

Goto rüstete sein HLISP mit dem Assocomp Feature aus, durch das Werte vonvorher spezifizierten Funktionen aufgehoben und automatisch mit assoziativen Mechanismen aufgesucht werden, wann immer dies möglich ist. So wird der gewöhnliche Auswertungsmechanismus, durch ein Tafelablesen ergänzt, nichtunwesentlich effizienter.

Als Basis-System des Formelmanipulationssystems REDUCE hat HLISP enormeRechenzeitverkürzungen erreichen helfen [GOT76].

1974 veranstaltete die Japanische Gesellschaft für Informationsverarbeitung ein Symposium über Symbolmanipulation. Anläßlich dieses Ereignisses organisierte man einen Vergleich der arbeitsfähigen LISP-Systeme, den {\em 1. LISP Contest}. Zehn verschiedene Systeme, die auf zehn verschiedenen Anlagen liefen, waren beteiligt. Neben den schon erwähnten Systemen HLISP (damals auf HITAC-5020), EDOS/EDOS-MSO LISP1.5, KLISP und EPICS-LISP1.6 waren die Testprogramme auch in den Systemen OLISP, LISP43 und T-40 LISP gelaufen. Die beiden übrigen Systeme sind leider nicht überliefert.

OLISP war von H.Yauis und einigen Kollegen an der Osaka Universitätimplementiert worden. Es war ein relativ kleines, aber recht effizientes System. Der Basisrechner hie\ssNEAC-2200. Nach 1974 ist das System, nun aufeinem NEAC 800-2, mit einem Compiler ausgestattet worden. Es hielt sich weitgehend an LISP1.5, behielt aber mit seinem eingeschränkten Nutzerkreis nur lokale Bedeutung.

LISP43 war von Y.Yoshida von der Nagoya Universität für eine OKITAC-4300erstellt worden. Es war als LISP für Mini-Rechner einzuschätzen. Gleiches gilt für das T-40 LISP der Universität Kyoto, von K.Nakamura für eineTOSBAC-40C programmiert.

Ein größeres System war das von S.Ono und Kollegen des MitsubishiElektrotechnischen Laboratoriums implementiert LISP/M, auf einer MELCOM-1000, das auch über einen Compiler verfügte.

Seit 1974 ist das Interesse an LISP in Japan äußerst lebhaft geworden. Dazu hat vielleicht auch Gotos Einführung in LISP [GOT74b] beigetragen. Während sich die Systeme HLISP, LISP1.6 und OLISP weiterentwickelten, wurden neue Implementationen unternommen: 1974 LISP1.5 von H.Kimura an der OkayamaUniversity of Science auf dem MELCOM COSMO-700, sehr eng an das originale LISP1.5 angelehnt, 1975 die Systeme NIT-LISP-U (T.Niwa et al., NagoyaInstitute of Technology) und VS-DLISP1.5 (H.Imura, Doshisha Universität)und LIPQ [TA75].

1976 sind sechs neue Implementationen entstanden (ALPS/I, HLISP-Compiler, LISP38, PETL, TLICS und LISP/P). 1977 kam noch FLISP hinzu und 1978 HITAC-10 LISP und LISP1.7. Die meisten dieser Systeme werden ebenfalls an der Ursprungsuniversität benutzt, oft nur von den Implementatoren. Nur das HLISP auf der HITAC 8800 bzw. 8700 und TOSBAC LISP1.9 haben größere Benutzerkreise erschließen können.

1977 wurde die Interessengruppe für Symbolmanipulation und Verarbeitung natürlicher Sprache gegründet. Ende 1977 bereitete diese einen neuen Vergleich vor, den LISP Contest 1978 [IPSL]. Daran waren diesmal neben 17japanischen LISP-Implementationen auch drei ausländische beteiligt:UT-LISP auf CDC6600, STANFORD LISP auf B1726 und DOS/ES LISP1.6. Es zeigte sich, da\ssviele japanische Systeme die Listenverarbeitung von LISP1.5 sehr effizient verwirklicht hatten. Inwieweit sie den Unterstützungsstandard amerikanischer Systeme oder angemessene Funktionsspektren hatten, war nicht ersichtlich.

In Japan wird LISP offenbar viel für Lehrzwecke verwendet. Daneben stehen die üblichen Anwendungsgebiete: Formelmanipulation, Sprachverarbeitung, Programmsynthese und -Analyse, Robotik und andere Gebiete der Künstlichen Intelligenz. Neuerdings ist in Japan sehr viel Aktivität bei der Entwicklung von LISP-Maschinen zu verzeichnen.

 

Kanada und Australien

Bezüglich Kanada war schon die Entwicklung des LISP/360 an der Universität in Waterloo durch Kent erwähnt worden, die durch J.F.Bolce und R.H.Cooper vollendet worden ist [BOL68].

Weitere eigenständige Implementationen scheinen nicht durchgeführt worden zu sein, da aus den benachbarten USA ständig neue Systeme erhältlich waren.

J.A.Campbell hat 1967 eine sehr frühe Version von UT-LISP (s.S. 232)und Kents 3600-LISP (s. S. 243) nach Australien gebracht. Das letztere liefauf einer CDC3600 in Canberra. Campbell hat das CDC6600 etwa auf den Standgebracht, den er früher schon mit seinem LISP1.6 am Imperial College (s.S. 236) erreicht hatte. Es wurde in Adelaide verwendet. Daneben sind nur Aktivitäten mit anderen Listenverarbeitungssprachen, etwa durch J.Hextmittels WISP (s.S. 236), bekannt.

 

Indien

In Indien ist LISP benutzt worden, seit Maschinen vom Typ IBM7090 oder ähnliche eingeführt worden sind. Eine heimische Implementation ist bekannt: Die von N.Soundarajan für den TDC-316, einen indischen Rechner.

 

Metasysteme

 

Einteilung

Ein Abri\ssder LISP-Geschichte kann nicht vollständig sein, ohne da\ssauch dieMetasysteme betrachtet werden,\footnote {Eigentlich gehörte auch eine chronologische Darstellung der Anwendungen hierher.} die auf den LISP-Implementationen aufgebaut wurden. Sind doch diese Systeme bzw. die durch sie realisierten Sprachen oft das Mittel gewesen, durch das die Nutzer mit dem LISP-System verkehrten.

Diese Metasysteme sind geschlossene Sprachverarbeitungssysteme, die auf der Grundlage von LISP implementiert sind (meist mit LISP selbst als Systemprogrammiersprache) und sich in der Syntax oft wesentlich von LISP unterscheiden. Häufig sind erhebliche Anleihen bei ALGOL gemacht worden, jedoch treten auch Programmiersprachen für linguistische Probleme (COMIT) als Vorbilder auf. Charakterisiert werden die Verbesserungen zu LISP meist durch Sprachelemente, die die Programme verständlicher machen sollen,\footnote{Was verständlich ist, kann nicht einfach entschieden werden. Im Fall von LISP waren dies meist Formen anderer Sprachen} und durch solche, die neue Verarbeitungsweisen ermöglichen. Diese letzteren sind meist Reaktionen auf neue entwickelte Methoden der Forschung auf dem Gebiete der Künstlichen Intelligenz.

Schon früh empfand man die Tatsache, da\ssLISP zwar an Einfachheit (diese wirdmanchmal als Eleganz bezeichnet) der syntaktischen Strukturen unübertroffen ist. Aber zur Erarbeitung komplizierter Programme durch den Menschen oder gar für Neulinge im Programmieren sind oft sehr schlecht lesbar und schwer verständlich; ihnen fehlt die Anknüpfung an die dem normal gebildeten Programmierer bekannten Notationsweisen.

Der Ablauf der Programme ist oft nur mit Mühe erkennbar; innerhalb der PROG-Blöcke sind undiziplinierte Programmierstile wie im gemeinsten FORTRANmöglich, und die freie Arbeit mit globalen Variablen und funktionalen Argumenten bereitet viele Verständnisschwirigkeiten. Andererseits kann kein Zweifel daran bestehen, da\sssolcherart angesprochene Sprachelemente wesentlich zur Ausdruckstärke von LISP beitragen.

Diese Nachteile von LISP wurden durch den Vergleich mit ALGOL evident. Schon 1961 dachte man über eine nachfolgende Sprachversion nach. Das Vorbild ALGOL deutete auf die Nützlichkeit deutlicher, durch Blöcke geordneter Variablengültigkeitsbereiche, zur Zyklenorganisation geeigneter Sprachelemete und diese bessere Lesbarkeit klammernarmer Ausdrücke (durch Einführung unterschiedlicher Klammern für mathematische Ausdrücke und Programmstrukturen sowie Vorrangregeln) hin.

 

Vor LISP2: Mustervergleich und systemunabhängige Eingabe

Durch die speziellen Anwendungsgebiete von LISP war das Augenmerk frühzeitig auch für die Sprachen gelenkt worden, mit denen Probleme der Zeichenkettenverarbeitung bearbeitet werden sollten, Eine von diesen, COMIT, wurde etwa gleichzeitig mit LISP am MIT entworfen [YN61,YN62,YN63a,YN63b].Hochinteressant war an dieser Sprache, da\ssder Autor Yngve eineGrammatikbeschreibung nach Chomskyschem Vorbild in eine Programmierspracheüberführt hatte. Um Sprachstrukturen zu beschreiben, notierte man Folgen von Terminalen und Nicht-Terminalen -- durch Trennzeichen(+ strukturiert). Die Nichtterminale wirkten wie Variable, für dieganze Klassen von Zeichenketten eingesetzt werden konnten. Auch Newell und Simon hatten beim Beweisen von aussagenlogischen Formeln mitMustern von Formeln gearbeitet, um eine mögliche Überführung durch Substitution festzustellen. Die vielfältige Verwendung machte den Mustervergleich (pattern matching) von Zeichenketten oder Formelstrukturen zu einer wichtigen Verarbeitungsweise nichtnumerischer Daten.

Bobrow, der sich mit der Verarbeitung natürlicher Sprache beschäftigte,wollte diese Möglichkeiten auch in LISP haben und baute sich auf LISP1.5 sein System METEOR auf [BO63a]. METEOR ist in gewissem Sinne das ersteMetasystem über LISP. Die Sprachelemente sind Regeln, die als LISP-Listen zu schreiben sind. Die Sprache selbst wird aktiviert durch den Aufruf des Interpreters (METEOR) und die Übergabe von Regelmengen und Daten alsArgumente. Für die Regeln werden einige Sonderzeichen als METEOR}-Syntaxelemente verwendet: \, \$ und \/ spielen hier eine besondereRolle. Die Regeln selbst bestehen aus sieben Teilen: Regelname, Ablaufinformation, Muster (linke Seite), Transformationsvorschrift (rechte Seite), Sektion zur Verwaltung temporärer Speicher, Name der nächsten Regel, Kommentar. Alle diese Elemente sind entweder echte Atome oder Listen.

Die Abarbeitung der Regeln findet normalerweise in folgender Reihenfolge statt: Es wird versucht, das Muster auf die bearbeitete Zeichenkette zu passen\footnote{Pattern Matching beinhaltet sowohl den Vergleich als auch die Identifizierung gewisser Teile und ihre Aufbewahrung.} Gelingt das, werden die Umordnungs- und Speichervorschriften ausgeführt und wird zu der angegebenen Regel gesprungen. Gelingt der Vergleich nicht, so wird zur nächsten Regel gegangen.

Die Muster werden durch literale Atome, Zahlen und Dollar-Elemente beschrieben. Die Linearität der Daten drückt sich darin aus, da\ssnach derMusterpassung die einzelnen Teile über Zahlen angesprochen werden müssen. Kommt eine Zahl im Muster vor, bedeutet dies die Wiederholung des entsprechenden Elements. Mit \$-Ausdrücken der Form (\$.N) können naufeinanderfolgende Elemente der Arbeitsspeichers bezeichnet werden. Durch \$0 kann eine Anfangs-bzw. Endposition, durch (\$.ATOM) und ähnlicheFormen können Datentypen bestimmt werden.

Alles in allem ist METEOR sicher kein ausgewachsenes Metasystem, da es sichdeutlich an die LISP-Syntax hält. Es verwendet insbesondere keine eigene Leseroutine. Mit der Einbettung einer zu LISP fremden Abarbeitungsart und der Aufnahme des Pattern Matching hat METEOR abernachfolgende Wirkungen ausgelöst.

METEOR(
(
 (CHANGE  ($ ROSE) (FLOWER)        (/ (*Q SHELF1  1 PRETTY))        CHANGE)
 (*       ($)      ((*A SHELF1) 1) (/ (*D PNTRET RULE3))            *)
 (PRNTWS *   ((*P THE WORKSPACE IS))                                PNTRET)}
 (RULE2   ($)                                                       END)
 (RULE3   (($.1) ($.1)) O (/ (*S ODD 1) (*Q EVEN 2) (*D PNTRET RULE3))}
                      PRNTWS  (THIS IS A CONTINUATION OF THE PREVIOUS CARD))
 (*       ($)      ((*A ODD) (*N EVEN)) (/ (*Q ODD (*N EVEN) ONLY)
                                   (*P ODD EVEN) (*D PNTRET RULE2)) PRNTWS))
((A ROSE IS A ROSE IS A ROSE))}

\begin{center}Abb. 10. Ein METEOR-Beispielprogramm [BO63a][Fig.4]\end{center}

Im Laufe des Jahres 1964 wird zur Verarbeitung LISP-fremder Syntax übergegangen. Ziemlich wahrscheinlich ist J.Hext der erste gewesen, der dieLISP1.5-Grundfunktionen für die zeichenweise Eingabe verwendete. Allerdings kontruierte Hext kein Metasystem, sondern entwickelte lediglich einenEingabeteil für die Umsetzung arithmetischer Ausdrücke in LISP-S-Ausdrücke. MATHREAD [HEX64a], wie die Hauptfunktionen hieß, konnte aber alsTeilprogramm für ein Metasystem dienen. Als solches ist dies Programm ein wesentlicher Teil des ersten REDUCE-Systems von Hearn gewesen, denndieser hatte das Programm von Hext gefordert.

Ausgehend von den Erfahrungen mit MATHREAD formulierte Hext allgemeineMethoden zum Umsetzen einer beliebigen Programmiersprache in das LISP-Format [HEX64b]. Allerdings scheint die Syntaxbeschreibung und dasUmsetzungsverfahren nicht in ein LISP-Programm für einen Compiler geflossen zu sein.

 

LISP2

Während dieses und ähnliche Programme für die Zwecke der Formelmanipulation zögernd entwickelt wurde, war das erste größere Projekt eines Metasystems in die Phase der Realisierung getreten: LISP2. Obwohl als Nachfolger und somitauf gleichen Niveau wie LISP1.5 stehend gedacht, ist LISP2 dochhauptsächlich als Metasystem entstanden und als solches wieder untergegangen.

Als die unbestimmten Diskussionen über ``die neue Sprache'' konkret wurden, waren inzwischen weitere Programmiersprachen entstanden, die als berücksichtigenswert erschienen. Unter diesen mu\ssSLIP [WEIZ63] erwähntwerden, wie FLPL eine auf FORTRAN aufgebaute Listenverarbeitungsprache, die aus einer zu FORTRAN hinzugestellte Menge von Unterfunktionen (größtenteils in FORTRAN geschrieben) bestand. SNOBOL [GRIE68], eine noch heute verwendeteSprache zur Zeichenkettenverarbeitung [FAR64], enthielt viele Änderungen undVerbesserungen in Bezug auf COMIT. Die weiterentwickelte Mittel zur Beschreibung der Muster und zum Beeinflussung des Vergleichsprozesses schienen höchst bedeutsam. Auch die Sprache TREET [HAI65] eröffnete neuePerspektiven. Sie basierte auf LISP\footnote {siehe [SAM66; O68}.] undverwendete aber ALGOL- bzw. FORTRAN-Notation für die Arithmetik und die Steuerung der Programme. LISP wurde erweitert durch eine Reihe von Funktionen, die für die Arbeit mit Bäumen vorteilhaft sind.

Es mag durchaus sein, da\ssdie LISP2-Entwicklung am Ende deshalbproblematisch wurde, weil sie in eine äußerst fruchtbare Phase der Informatik fiel und so viele neue Ideen geäußert wurden, da\ssdiese kaum voll durchdachtaufgegriffen werden konnten.

Die Arbeit an LISP2 begann 1964 erst richtig, als die LISP1.5-Implementation auf der Q-32 der SDC lief (vgl. Kapitel 4). Mitarbeiter der Firmen Information International Inc. und Systems Development Corporation waren für die Festlegung des Sprachumfangs und für die Implementation verantwortlich, wobei der Q-32 als Basisrechner dienen sollte. Beraten wurde das Team dabei von Wissenschaftlern aus Stanford und vom MIT.

Vom MIT scheinen hauptsächlich Vorschläge für die Zechenkettenverarbeitung gekommen zu sein. im Jahresbericht 1964--1965 wird der Standpunkt aus der Sicht des MIT wie folgt dargelegt: ``LISP2 bekommt dynamischeSpeicherverwaltung, rekursive Funktionen und dynamische Felder. LISP2enthält Listenverarbeitung wie das gegenwärtige LISP1.5, jedoch wird die Kontrollsprache eher ALGOL als LISP sein. Dabei werden die benutzten Listenstrukturen kompaktiert, um Platz für die Bereitstellung von Feldern und neuen Listenelementen zu bekommen.

LISP2 wird formatgerichtete Zeichenkettenverarbeitung enthalten, ähnlichwie in der Programmiersprache COMIT. Innerhalb dieser Verarbeitung kann der Nutzer ein Muster angeben, mit dem eine Zeichenkette verglichen wird. Ist der Vergleich erfolgreich, dann wird die Zeichenkette in Teile zerlegt, die den verschiedenen Teilmustern entsprechen ...

Der Compiler für LISP2 wird hergestellt, ausgehend von einemBootstrapcompiler, der in LISP1.5 geschrieben wird. Der eigentliche Compiler wird fast völlig in LISP2 programmiert, so da\ssLISP2 recht unabhängigvom Maschinentyp sein wird. Wir erwarten, da\ssauf folgenden MaschinenVersionen aufgebaut werden: Q-32 bei SDC, IBM/360, DEC pdp-6, GE645 ... Eine erste Version wird bald auf dem Q-32 bei SDC arbeiten. '' [PROM2].

Bekannte Beiträge vom MIT sind die Memos von Bobrow über dieZeichenkettenverarbeitung [BO64b] und die Musterbeschreibung [BO65] sowieLevins Vorschlag zur Syntax [LEV63]. Nach Bobrows Wechsel zu BBN (Anfang1965) und der Lieferung der pdp-6 und der Implementierung des neuen LISP-Systems für diese Maschine sind vom MIT wenig konkrete Teilleistungen bekannt. Man hatte genug mit sich selbst zu tun, und die Implementation von LISP2 schien auf dem rechten Weg.

Auch von Stanford kamen zunächst viele Beiträge: McCarthy machte sich umdie Basisdatenstrukturen Gedanken und um die grundlegenden Operationen über diesen [MCC63f]. Im August 1964 wurde sogar ein Vorschlag für eineSprachdefinition gemacht [MIT64]. Inhalt dieses Positionspapiers istpraktisch eine Erweiterung von ALGOL60. Die erforderlichen neuen Elemente wurden nicht nur im Bereiche der Listenverarbeitung (Datenstrukturen, Operatoren und Standardfunktionen sowie angepaßte Zyklenkonstruktionen) gesehen, sondern auch auf dem Gebiete der Erweiterbarkeit der Sprache. Neue Datentypen, Operatoren und syntaktischen Konstruktionen sollten definierbar sein.

Schließlich schlug man als Änderung zur ALGOL60-Semantik die Eliminierung der Parameterübergabe Call-By-Name vor.

Obwohl Stanford sehr nahe bei Santa Monica gelegen ist, scheinen auch in diesen Fall direkte Zuarbeiten seit Anfang 1965 unterblieben zu sein. Es ist nicht klar, ob dies auf bessere Vorschläge aus dem Implementatorenteam oder auf Meinungsverschiedenheiten hindeutet.

Nach allem, was an Vorschlägen aus dem MIT und von Stanford erwähnt worden ist, kann schon die übergroße Aufgabe des Teams um Abrahams ermessenwerden, das unreale Wunschvorstellungen verwirklichen sollte.

1966 war die Implementation so weit gediehen, da\ssim Herbst in einem großenBeitrag zur FJCC berichtet wurde [AB66b]. Demnach sollte LISP2 durch zweiSprachniveaus gekennzeichnet sein: Die Quellsprache, das eigentliche LISP2, war ALGOL-ähnlich; die Zwischensprache entsprach LISP1.5. Durch dieEinführung neuer Datentypen (Felder, Zeichenketten, gepackte Datentabellen) und neuer Operationen (Teilwortextraktion und -einschub sowie der mustergesteuerten Datenverarbeitung), sollte ein wirklich tragfähiges System entstehen. 1966 war noch nicht alles fertig implementiert, doch die wesentlichen Teile waren bereits gut zu erkennen.

LISP2 erlaubte folgende Datentypen: Boolesche Werte, Integer,Oktalzahlen, Realzahlen, funktionale Elemente, Symbole und Felder. Die funktionalen Elemente entsprachen den LISP-Funktionen, die sowohl als Argumente als auch Werte einer Funktion auftauchen dürfen. Der Datentyp ``Symbol'' kann den S-Ausdrücken von LISP1.5 zugeordnet werden. Die Elemente der Felder durften jedes anderen Typs sein, nur nicht wieder Felder (Array).

Die Ausdrücke (Programme) waren ähnlich wie in LISP definiert: Sie setzten sich aus Konstanten und aus Variablen zusammen. Quotiert wurde durch einen vorangestellten Apostroph (möglicherweise eine Erfindung von LISP2). Manunterschied drei Variablentypen: Fluid, Own und Lexical. Die Fluid-Variablen entsprechen in gewissen Sinne den dynamischen Variablen vom SPECIAL-Typ\footnote{d.h. gebunden von einer Funktion und frei inUnterfunktionen}, die Own-Variablen dienten zur Koorperation mit LISP2-fremden Programmen und die lexikalischen Variablen sind dengewöhnlichen lokalen Variablen zuzuordnen.

Um Funktionsanwendungen auf Argumente auszudrücken, wurden die operationalen Formen benutzt. Die Bezeichnung der Funktion stand wie in ALGOL vor der Argumentliste. Es gab die Möglichkeit, mit MACRO zu arbeiten. Auch Infix-und Präfixoperatoren für alle möglichen Arten von Operationen waren zugelassen. So wurde für CONS der Vorschlag von Mitchell aufgegriffen,den Punkt als Operator zu benutzen, für die CAR und CDR-Operationen hatman sich aber keinen neuen Bezeichnungen entschließen können.

Die Blockstrukturen waren von ALGOL übernommen. Deklarationen mußten (einschließlich optionaler Anfangswerte) am Blockanfang getätigt werden. Eine Reihe von Anweisungstypen sollte die Strukturierung des Programmtextes ermöglichen: Man verfügte über CASE, FOR, GO, RETURN, TRY, bedingte,Verbund- und Blockanweisungen sowie bedingte und blockausdrücke.

Ein neues Element stellt hier die TRY-Anweisung dar, die zur Einrichtung vonVerarbeitungsniveaus dient (ähnlich zu ERRORSET in LISP1.5): Tritt in einemAusdruck oder in einer Anweisung im Innern der TRY-Anweisung eineEXIT-Bedingung auf, so wird die Steuerung der TRY-Anweisung zurückgegeben.

Man hatte versucht, für die Ein- und Ausgabe günstige Datei-Verarbeitungsmöglichkeiten zu schaffen. Ähnlich wie in LISP1.5 hatte man sich auch LISP2 als interaktiv gedacht, so da\ssständig nur einEingabedatei und ein Ausgabedatei aktiv sein konnte. Durch einfachen Wechsel der Ein- und Ausgabezuordnung konnte so jedes physische Gerät bedient werden. Mit dieser Freiheit war LISP2 ein Vorbild für die später entstehendenSysteme LISP1.6 und BBN-LISP.

Das LISP2-Programmiersystem war gekennzeichnet durch die Koexistenz desLISP2-Syntaxtranslators, der aus der quellsprache LISP2 die internen(LISP1.5) S-Ausdrücke bildete, und dem LISP2-Verarbeitungssytem. derLISP2-LISP1.5-Umsetzer war mit Hilfe eines Compiler-Compilers erzeugtworden. Er wurde von einem Scanner bedient, der als endlicher Automat arbeitete.

Die Besonderheit der Funktionsbehandlung im LISP2-System bestand in dersofortigen Compilierung der eingelesenen Funktionen und folgte darin dem Q-32-LISP1.5 [SAU 64b]. Der Compiler war, wie in LISP üblich, in deneigentlichen Compiler und das Assemblerprogramm aufgeteilt und enthielt eine Reihe von Optimierungsstufen. Bei der Speicherverwaltung wurde ein Gemisch aus Kelleranordnung von Zahlen und Variablen sowie dynamischer Listenspeicher mit kompaktierendem Garbage Collection verwendet.

Das LISP2-Team bestand aus bewährten Spezialisten der LISP-Implementation.Neben Abrahams müssen Levin, Saunders, S.Kameny, C.Weissman (Verfasser des LISP1.5-Primers[WEIS67]) sowie {\sc J.A.Barnett, E.Book, D.Firth} und Hawkinson erwähnt werden.

Mitte 1966 lagen schon wesentliche Teile der Dokumentation vor, ein von Levin geschriebener Primer [LEV66] und das von Abrahams stammendeReference Manual [AB66a].

Die ersten Erfolge schienen sehr vielversprechend, doch dann kam eine unvorhergesehene Komplikation: Obwohl die Implementation auf anderen Rechnern vorhergesehen war, wäre doch die Sprache mit dem auf dem Q-32 aufgebauten System erst einmal zu popularisieren gewesen. Auf Grund des Fernzugriffs zum Q-32 stand dem nichts im Wege. Doch dieser wurde nun durch eine IBM/360.50 ersetzt.

So mußte, ohne da\ssvon ernsthaften Nutzern die Rede war, bereits mit derzweiten Implementation begonnen worden. Schon Anfang 1967 sind alle wichtigen Entscheidungen gefallen, eine Serie von Beschreibungen wird fertiggestellt [BAR67a, b, c, d, FIR67, WIL67]) und die Implementation war in vollem Gange.

Außer dem LISP2-Projekt arbeitete man bei SDC auch an demTime-Sharing-System ADEPT [LI69] für die IBM/360.50. Möglicherweise hat mandamals geglaubt, mit Betriebssystem und allgemeiner Programmiersprache IBM ausstechen zu können. Doch man hatte offenbar nicht das Geld, um LISP2, das derweil der PL/I-Krankheit des ``Feature-Krebs'' (``Mehr, mehr,mehr ...!!'') anheimgefallen war, zu halten.

Trotz der vielen Vorschußlorbeeren und der hochgespannten Erwartungen erwies sich LISP2 nicht als der große Erfolg, den sich die Mitarbeiter undvermutlich auch die beteiligten Firmen erhofft hatten. Seit 1968 ist praktisch nicht mehr die Rede von diesem System, das also einen jähen Absturz genommen haben muß. Lediglich J.Sammet berichtet in ihrem Buch über dieGeschichte der Programmiersprachen, das erst 1969 erschien, noch mit mehr als lobenden Worten über das LISP2-Projekt. Aus Kreisen der Forschung zurKünstlichen Intelligenz sind erst später spärliche Stimmen zu vernehmen: ``Das abgebrochene (aborted) LISP2-System ...'' [FEN71] oder ``Leiderentwickelten sie es zu Tode ...'' [EAR73].

Wesentliche Hinweise auf die Ursachen der gedämpften Aufnahme gab J.Weizenbaum in seiner Besprechung der LISP2-Veröffentlichung 1967 [WEIZ67]:Seiner Meinung nach hätten die Autoren von LISP2 wesentliche Eigenschaften vonLISP1.5 aufgegeben, ohne entsprechend wichtige Vorteile vorweisen zu können. Da die meisten der durch LISP2 gelieferten Möglichkeiten auch in vielenanderen Programmiersprachen, so z.B. in PL/1, aufbaubar seien (unter anderem auch die mustergelenkte Datenmanipulation), bestünde nun nicht mehr viel Grund für LISP2.Als wichtige und einzigartige Eigenschaften von LISP1.5 nannte Weizenraumdie ``Einfachheit, mit der Programme als Daten behandelt werden können (ein gerade aktives Programm kann verarbeitet werden und eine resultierende Struktur kann wieder als Programm behandelt werden)...'' [WEIZ67].Außerdem bemängelte Weizenbaum den Verlust der Interpretation alsVerschlechterung der Atmosphäre bei der Programmentwicklung und das kompaktierende Garbage Collection. Er prognostizierte für das letztere bei Rechnern der Größe von 200 000 Worten eine Zeitdauer von 200 Sekunden und meinte, da\ssdies unerträglich sei.

Ganz offenbar hatte keiner der in die Diskussion um die Ziele des LISP2-Projekts verwickelten Wissenschaftler an diese Eigenschaften vonLISP1.5 gedacht. Insofern hat das LISP2-Projekt gerade durch sein jähes Ende wichtige Einsichten in die mehr zufällig entstandene LISP1.5-Sprache gewährt.

Abrahams erwähnt die von inhaltlichen Fragen abgeglittene Verfolgungdes Projekts und die fehlerhafte Konzentration auf die Effizienz: ``Während sich das Projekt entwickelte, wurde es mehr ambitioniert, und ein großer Teil der Mühen wurde auf die Optimierung verwandt. Der größte Fehler des Projekts war, zu versuchen, da\ssdie erste Implementation von LISP2 auch die bestesei, statt blo\sseinen Interpreter zu liefern, um das Projekt abzusichern. Esgab schon genug Schwierigkeiten, um das System auf der Q-32 zu implementieren, und so wurde das Projekt überdies noch verwirrt durch einen Vorstoß, auf die IBM/360 überzugehen. Das Projekt brach schließlich zusammen, weil es Ressourcen verbraucht hatte, die im keinem Verhältnis zu dem langsamen Fortschritt standen. Wir versuchten allzuviel zu erzielen und taten dies in der falschen Reihenfolge...'' [AB76].

Hawkinson sieht weitere Gründe für das Versagen einerseits darin,da\ssLISP2 die Tendenz zur interaktiven Benutzung von LISP nicht genügendwahrgenommen hatte. Dies wäre einfach kein vordringliches Entwurfsziel gewesen, und das war ein grober Fehler. Andererseits wurde LISP schon zu jeder Zeit mehr und mehr zu einer Implementationssprache für andere Systeme und sei weniger verwendet worden, um Anwendungsprogramme zu schreiben. ``Schöne Syntax und vielfältige Datentypen sind einfach nicht wichtig für die Implementation einer Programmiersprache höheren Niveaus''. Eine Rolle hätten ferner die singuläre Maschine und die Tatsache gespielt, da\ssschließlichkein ``wichtiger'' LISP-Experte mehr beteiligt gewesen sei...

Es scheint, da\ssder negative Ausgang des LISP2-Projekts eines derwichtigsten Ereignisse auf dem Gebiet der Künstlichen Intelligenz und vielleicht auf dem Programmiersprachensektor (vergleichbar mit dem Ende von ALGOL 68) in den sechziger Jahren gewesen ist. Das Unterbleiben einer Analyse dieser Ereignisses hat vermutlich zu weiteren vergleichbaren Mißerfolgen beigetragen. Viele der seit einigen Jahren zu beobachtenden Vorgänge um CommonLISP sind den damaligen sehr ähnlich. Gemeinsame Ursache ist das Unverständnis der Eigenschaften, die eine gute Programmiersprache ausmachen. Seinerzeit handelte es sich um LISP1.5, das nicht recht verstanden worden ist. heute sind die vielen meist willkürlichen Neuerungen und Erweiterungen der siebziger Jahre unverdaut. So kann man nicht viel mehr sagen als: LISP2 kam zu früh...

{\tt

FU\=NCTION LCS(L1,L2); SYMBOL L1, L2;
   BE\=GIN \=SYMBOL X,Y, BEST $\leftarrow$ NIL; INTEGER K $\leftarrow$ O;
         N, LX $\leftarrow$ LENGTH(L2);
   FO\=R X ON L1 WHILE LX > K DO
    BE\=GIN INTEGER LY $\leftarrow$ LENGTH (L2);
     FO\=R Y ON L2 WHILE LY > K DO
      BE\=GIN  $\leftarrow$ COMSEGL (X,Y);
       IF N <= K THEN GO A;
       K $\leftarrow$ N;
       BEST $\leftarrow$ COMSEG(X,Y);
      A: LY $\leftarrow$ LY-1
      END
     LX $\leftarrow$ LX-1
    END;
   RETURN BEST;
  END;

}\begin{center}Abb. 11. Ein LISP2-Beispielprogramm [AB66b][S. 670]\end{center}

\subsection {Zwischen LISP2 und PLANNER: CONVERT, FLIP, MLISP und Formelmanipulationssysteme}

1965 entstanden fast gleichzeitig zwei Systeme, die als Weiterentwicklung von METEOR gedacht waren: CONVERT [GUZ66] und FLIP [TE65b]. Die Absichtdieser Systeme war, die Orientierung auf lineare Listen (als Darstellungen von Zeichenketten) zu erweitern und Mustervergleichsprozesse für beliebige S-Ausdrücke zu ermöglichen. Beide Systeme waren in LISP eingebettet, d.h., sie waren, ähnlich wie METEOR, als Systeme von LISP-Funktionenprogrammiert. Die Elemente der Mustersprache tauchten als gewöhnliche Argumente der Hauptfunktion auf, für ihre Formulierung wurden Sonderzeichen verwendet, die in LISP keine Rolle spielten.

CONVERT, entwickelt von Guzman und McIntosh in Mexico City,scheint die etwas schwerfälligere, langsamere und sich Modifizierungen widersetzende Schwester gewesen zu sein. In den Formulierungsmitteln erreichte CONVERT aber praktisch die Qualität von Teitelmans FLIP.

In FLIP besteht jeder Programmschritt, als Aufruf der Hauptfunktion FLIP,aus einem Mustervergleich und einer anschließenden Konstruktion, die durch ein Format gesteuert wird. Muster und Formate haben etwa gleiche Syntax, wobei letztere natürlich wesentlich einfacher sind, da der eigentliche Lokalisierungsproze\ssfür die Teile im Mustervergleich absolviert ist.

Die Muster werden fast mit denselben Zeichen beschreiben, wie sie in METEORbenutzt wurden: zu \}, \$ und / kommt nur = neu hinzu. Die Muster könnendurch \$-Elemente für Segmente, durch Literale in Form beliebiger S-Ausdrücke und durch Ausdrücke, die auszuwerten sind, beschrieben werden. Unterlisten dienen als Muster, die in tiefere Listenniveaus weisen. An beliebiger Stelle des Muster können frühere Teile desselben referiert werden. Für die Referenzen sind Musterelemente gedacht, mit denen man sich auf das Hauptniveau des Musters, auf das aktuelle Niveau und auf beliebige Zwischenniveaus beziehen kann. Erst dadurch wird die Verwendung der strukturierten Muster eigentlich schlagkräftig.

Mit speziellen Atomen, wie \$\*,\//, usw., konnten recht spezielle Aktionen wie z.B. die Prüfung von Eigenschaften der Musterteile, die mit den Musterbeschreibungsmitteln nur schwer auszudrücken wären, oder die unmittelbare Beendigung des Musterpassungsprozesses erreicht werden.

FLIP übersetzte Regeln, die aus konstanten Elementen bestanden, ineffiziente LISP-Programme. Damit war ein Schnitt über die bloße Einbettung hinaus getan.

Teiltelman selbst paßte FLIP in sein umfassendes System PILOT [TE66]ein. Dort konnte es sowohl von den LISP-Programmen benutzt werden, diente aber auch für die Errichtung eines bequemen Interfaces für den Nutzer. Auch in dem Teil von PILOT, der für die Änderung der Programme gedacht war, demEditor, wurde FLIP eingesetzt. PILOT war als Test- und Änderungshilfe fürLISP-Programme gedacht und enthielt für diese Zwecke neben dem Editor das System ADVISE (zum Ändern der Eintritts- und Austrittselemente vonFunktionen, damit also zur Beeinflußung der Beziehungen der Funktionen untereinander). Auch die Unterbrechungsfunktionen wie BREAK sind in dasGesamtsystem integriert (vgl. auch [TE65a]).

In einer weiterentwickelten Version von FLIP [TE67] werden einige derunschönen Stellen bereinigt: Zur Bezugnahme auf Musterelemente werden nicht mehr Zahlen, sondern spezielle Atome (mit \# beginnend, allerdings folgt danach die alte Zahl) verwendet. Um die Literale sorgfältiger von zu berechnenden Musterelemente zu trennen, sind erstere zu quotieren (mit '). DieZahlen hinter \$ (um Segmente einer gewissen Länge zu bezeichnen) bzw \# sinddurch beliebige Ausdrücke ersetzbar, die einen numerischen Wert haben. Die Prädikate können jetzt den Teilmustern oder Musterelementen direkt zugeordnet werden. Dabei wird die Bezugnahme auf das zugeordnete Element über den Stern $\*$ vollzogen.

Eine kürzere Formulierung von Muster wird mit Hilfe der Schlüsselwörter EITHER (Alternativen von Muster) und REPEAT (Wiederholung) erreicht. GanzeRechnungen während des Musterpassens können mit Hilfe der Zuweisung SETerreicht werden.

Etwa zur gleichen Zeit entstanden mehrere Systeme zur Formelmanipulation in LISP. Im Unterschied zu den zeitgenössischen Programmsystemen für die Künstliche Intelligenz schien für die Nutzer eines Formelmanipulationsystems nicht die LISP-Notation, sondern eine möglichst übliche mathematische Schreibweise erforderlich.

(DEFINE ((FORMTRAN(LAMBDA(U)(CONVERT
(LIST)
(QUOTE(X(LL)(RR)))
U
(QUOTE(*(
       ((LLL P RRR)(P(=BEGN=(LLL))(=BEGN=(RRR))) )
       ((LLL M RRR)(M(=BEGN=(LLL))(=BEGN=(RRR))) )
       ((LLL * RRR)(A(=BEGN=(LLL))(=BEGN=(RRR))) )
       ((LLL / RRR)(/(=BEGN=(LLL))(=BEGN=(RRR))) )
       ((LLL ** RRR)(**(=BEGN=(LLL))(=BEGN=(RRR))) )
       ((X)(=BEGN= X))
       (()_0)         )))   )))   ))

\begin{center}Abb. 4.12 Ein CONVERT-Beispielprogramm [BO68b][S.4142]\end{center}

(DEFINE((DERIV(LAMBDA(EXPR VARBLE)(TRANSFORM EXPR
      '((==VARBLE 1)
       (\$1[ATOM*] 0)
       ((.. + ..)  (SPLUS DL DR))
       ((.. - ..)  (SMINUS DL DR))
       ((.. * ..)  (SPLUS (STIMES LL DR)(STIMES DL RR)))
       ((.. / ..)  (SDIV(SMINUS(STIMES RR DL)(STIMES LL DR))
                                           (SEXPT RR2)))
       ((.. ^ ..)  (STIME RR (STIMES SEXPT LL (SMINUS RR 1))
                                           DL))))
   NIL
   '(K    PAV  $1[NUMBERP*]
     L    PAV  $1[NUMBERP*]
     LL   SKEL =(UNLIST #1)
     RR   SKEL  =(UNLIST #3)
     DL   SKEL  ( = (UNLIST =/= 1))
        ...

\begin{center}Abb. 4.13. Teil eines FLIP-Beispielprogramms [TE67][S. 84]\end{center}

Während MATHLAB [ENG65] das Problem der Eingabe noch völlig ignoriert hatteund vom Nutzer die Umsetzung in LISP-Ausdrücke erwartete, lieferte es immerhin lesbare Resultate [ENG66].

Ähnlich standen die Dinge um das ``Symbolische Mathematische Labor'' von {\sc Martin} [MART67]. Einem Vorschlag Minskys folgend [MIN63b], hatte sichMartin um die möglichst getreue Ausgabe mathematischer Ausdrücke auf einemBildschirm bemüht und um Möglichkeiten, diese Ausdrücke mit Lichtgriffel und Tastatur sowie die Symbolmanipulationssystem zu bearbeiten bzw. zu verändern. Die ursprügliche Eingabe wurde durch Martin wenig behandelt.

REDUCE [HEA67] hat sich dagegen unter Benutzung des Hextschen Programms[HEX64a] von Anfang (1964) an sowohl in der Eingabe als auch in der Ausgabevon LISP gelöst und übliche mathematische Notation geboten. Ähnlich ist dann auch SCRATCHPAD [GRI71b] vorgegangen. Zu einem echten Metasystem wurdeREDUCE2 [HEA73], der zwischen 1968 und 1970 entwickelte Nachfolger. Neu wardie durchgängige Aufnahme einer ALGOL-ähnlichen Notation für Daten und Programme. Diese über der LISP-Basis ausgebreitete höhere Programmiersprache konnte nun auch für andere Zwecke als Formelmanipulation genutzt werden [LUX75a] und wird heute RLISP genannt. RLISP führte viele derGrundoperationen von LISP Infixoperationen ein\footnote {= für EQUAL, .für CONS}, erlaubte gemä\ssden üblichen Vorrangregeln die Notationklammernfreier Ausdrücke und bot einige Anweisungen zur Strukturierung der Programme, unter denen das FOR-Statement hervorzuheben ist. Es folgtehierin MLISP, dem ersten echten Metasystem [EN68].

Schon im SHARE-LISP, d.h. in der von Stanford seit 1965 vertriebenen Version des LISP1.5 für die IBM/7090, hatte es einzelne Funktionen für die Ablaufsteurung gehabt, die Namen von ALGOL-Schlüsselworten ableiteten ([MCC62c], Ausgabe 1965, S. 98). Als das STANFORD LISP/360 Ende 1967arbeitsfähig war, begann H.Enea mit der Implementation einesPräprozessors für die M-Sprache. Dieser sollte die alten, fast vergessenen M-Ausdrücke wieder aufleben lassen und damit die Nutzer von den vielen Klammern befreien.

MLISP führte Infixoperatoren für die wesentlichen arithmetischenOperationen ein. Nur für EQUAL und APPEND, als zwei Operationen überS-Ausdrücken, gab es ebenfalls Infixoperatoren (= bzw. @). Präfixoperatorenwaren +, -, NOT, NULL, ' und ATOM. Während jede beliebige Funktion vonzwei Argumenten mit ihren Namen als Infixoperator zugelassen war, galt dies nicht für Präfixoperatoren.

MLISP war wie LISP eine Ausdruckssprache, d.h., alle Sprachelemente warenmit Wert gedacht. Neben der Zuweisung und dem bedingten Ausdruck hatte man einige Zyklenkonstruktionen (FOR, UNTIL, WHILE) entwickelt, die nebengewöhnlicher ALGOL-ähnlicher Abarbeitung auch eine Variante enthielt (COLLECT), in der die Teilergebnisse in einer Resultatsliste gesammeltwurden. Für die häufige LISP-Operation LIST war eine besondere syntaktischeKonstruktion entwickelt worden. Schließlich war auch die Funktionsdefinition in MLISP formulierbar.

Mitte 1968 war MLISP einsatzfähig und wurde lediglich als Präprozessorbenutzt, d.h. die MLISP-Programme wurden direkt in LISP übersetzt undkonnten als solchen ausgeführt werden.

Als dann Ende 1968 die pdp-10 arbeitete, wurde ein ähnliches System für LISP1.6 gefordert. D.C.Smith implementiert MLISP und brachte einigeErweiterungen ein: Gleitkommazahlen, Zeichenketten, eine neue Form des FOR-Ausdrucks sowie verbesserte Fehlerreaktionen [SM69]. Mit der wachsendenKomplexität der Sprachkonstruktionen und dem nun eingerichteten Fehlerniveau (ERRSET), kam es zu einer gewisse Trennung der normalenLISP-Vearbeitung von der teilweise schon erheblichen MLISP-Interpretation.Allerdings kann die interne Repräsentation der MLISP-Programme überhauptnicht von der des Wirtsystems LISP unterschieden werden.

Im Laufe des Jahres 1969 hat Smith MLISP zu dem Stand weiterentwickelt,auf dem es dann lange Zeit benutzt worden ist[SM70]. Wesentliche Neuerung waren dieVektoroperationen, die aber andererseits, insbesondere durch die Vektorzuweisung, den Grad der Interpretation erhöhten. Vektoren konnten nämlich bezüglich der Zuweisung in zweierlei Art verstanden werden: Einmal konnte man ein Element ändern, so wie das nicht anders erwartet wird: Ist L ein Vektor (d.h. eineListe) der Form (A B (C D) E) F), so hat die Zuweisung

\begin{center}\tt L[3,1] $\leftarrow$ 1\end{center}

die Folge, da\ssder Vektor L nun A B (1 D) E F) ist.

Eine Vektorzuweisung (decomposition assignment) aber betrachtet die Elemente des Vektors als veränderbare Variablen und ändert ihre Werte in Abhängigkeit von der Struktur:

\begin{center}\tt L $\leftarrow$ '(1 2 (3 4 5 6 7) (8 9))\end{center}

löst folgende Veränderungen aus: A hat nun den Wert 1, B den Wert 2, Cden Wert 3, D den Wert 4, das Stück 5 bis 7 wird ignoriert, ebekommt den Wert (8 9) und F, da kein Element mehr übrig ist, den WertNIL. Man sieht leicht, da\sssich mit dieser Zuweisung ein guter TeilMusterpassungsoperationen durchführen läßt.

Die Erfahrungen mit der Konstruktion des Syntaxanalysators in LISP führte Smith und Enea schließlich dazu, da\sssie ähnlich wie Hext [HEX64b] einallgemeines Schema für die Umsetzung einer Sprachbeschreibung in BNF in einen LISP-Umsetzer entwickelten (SDIO). Die Fortschritte anderer Kollegen, speziell am MIT und am SRI, führten die beiden schließlich zu MLISP2.

REVERSE2 := #L:
IF NULL THEN NIL ELSE REVERSE2(CDR(L)) @ ;
REVERSE3 := *L:
  BEGIN NEW I, V; SPECIAL I, V;
    FOR I IN L DO V <- I CONS V;
    RETUNR(V);
  END;
REVERSE4 := #L:
  BEGIN NEW V; SPECIAL V;
    WHILE L DO PROG2(V <- CAR(L) CONS V, L <- CDR(L))
    RETURN(V);
    END;

\begin{center}Abb. 4.14. Ein MLISP-Beispielprogramm [SM69][S. 29]\end{center}

 

\subsection {PLANNER: backtracking, Pattern Matching und deduktive Mechanismen}

Das wesentlich neue Element, das in die Diskussion um neue Ausdrucksmittel für die Programmierung auf dem Gebiete der Künstlichen Intelligenz trat, war die Akzeptierung des Backtracking als brauchbarem Steuerprinzip.

Ein Programm verwendet Backtracking, wenn es an gewissen, nicht vollständig analysierbaren Stellen alle temporäre Information rettet und versuchsweise weiterarbeitet. Diese Stellen heißen Entscheidungspunkte. Gelangt dasProgramm auf dem eingeschlagenen Weg zum Ziel, dann war die Entscheidung richtig und die gerettete Information ist nicht mehr erforderlich. Wird das Ziel aber nicht erreicht, sei es, weil eine zeitschranke abgelaufen ist, oder weil ein Fehler die Verarbeitung unterbricht, dann wird am Entscheidungspunkt erneut angesetzt. Unter den geretteten Informationen, mit deren Hilfe der alte Zustand so weit wie notwendig wiederhergestellt wird, befinden sich auch solche, die weitere mögliche Alternativen betreffen.

Diese werden nun in ähnlicher Weise wie die erste durchprobiert.

Ein unerwünschter Zustand tritt nur ein, wenn alle Alternativen versagen. In diesem Fall mu\ssman die Vorgeschichte mit in Betracht ziehen: War derEntscheidungspunkt der einzige, dann kann das gesamte Programm nur erfolglos beendet werden. Liegen aber vor dieser Entscheidung noch weitere, verfahren, als ob das Programm bei der Verfolgung der aktuellen alternative des vorletzten Entscheidungspunktes einen Fehler beemerkt hat: Der letzte Entscheidungspunkt wird aufgehoben und am vorletzten Punkt erneut angesetzt.

Schon in Abrahams Beweisüberprüfer [AB63] ist dieses Verfahren angewendetworden. Für diese Zwecke wurde etwa 1961 die ERRORSET-Funktion erfunden,die über die Wiederherstellung eines gewissen Zustands wacht. Die Veröffentlichung von Golomb und Baumert [GOLO65] hob wahrscheinlich zumerstenmal das Backtracking als Programmierprinzip ab.

Durch das Erscheinen dieser Arbeit war die Diskussion um die methodologische Verwendung des Backtracking auch am MIT erst richtig in Gang gekommen,obwohl es schon vorher als Programmierprinzip benutzt worden war. Automatisches Backtracking nahm dann Hewitt in das Verarbeitungsmodell seiner Sprache PLANNER auf.

PLANNER galt zunächst als Theorembeweiser und dann als Instrument zurSteuerung von Robotern. Mit der Zeit wurde es aber mehr und mehr zu einem Spiegelbild von modernistischen Ideen auf dem Gebiet der Künstlichen Intelligenz und der Programmiermethodik.

Die erste Veröffentlichung über PLANNER erschien 1967 [HEW67]. Nach diesemAnfang wurden schnell weitere Ideen integriert, und 1969 bestand PLANNERmehr aus einem Komplex von verschiedenen Ideen bzw. Teilsystemen: Ein Teil bezog sich auf Mustervergleich, ein Teil umfaßte die Sprachelemente zur Ablaufplanung und enthielt dafür sowohl imperative als auch deklarative Elemente, einen weiteren Teil machte das mustergesteuerte Information Retrieval System aus, und schließlich wurde die Abarbeitung gesteuert durch das deduktive System und die hierarchische Kontrollstruktur [HEW69].

Für die Mustervergleich wird eine Notation benutzt, die zusammenfassend als muster-basierte Programmiersprache MATCHLESS bezeichnet wird. Die Ideendafür stammen nach Hewitts eigenen Angaben [ebd.] von derProgrammiersprache CONVERT [S. 279]; sie sind durch das Studium vonPostschen Produktion bzw. allgemeinen regulären Ausdrücken weiterentwickeltworden.

Von CONVERT übernahm Hewitt bei der Beschreibung der Muster dieBenutzbarkeit beliebiger Namen als Mustervariablen -- gegenüber der Beschränkung auf Zahlen in COMIT, METEOR oder FLIP. Ähnlich wie inCONVERT war weiterhin der Typ zu deklarieren: Vorhanden waren die TypenPointer, Atom, Segment, Integer, Gleitkommazahl, S-Ausdruck.

Im Unterschied zu allen Vorbildern, doch eine gewisse Entwicklung in FLIP aufgreifend, wurden Präfixzeichen eingesetzt, um verschiedenartigen Gebrauch der Mustervariablen anzuzeigen. So bedeutete ein Präfix \$, da\ssderfolgenden Variablen beim Mustervergleichsproze\ssein Wert zugeordnet werdendarf, \$\$ besagte, da\ssdie folgende Variable nur zu einem Objekt paßt, dasihren Wert entspricht, \$?, da\ssdie Variable einen Wert bekommen darf,falls sie noch keinen hat, ansonsten paßt sie nur zu ihrem Wert, usw.

Die Muster sind durch bestimmte Funktionen verknüpfbar. Diese liefern keinen Wert, sondern haben nur Sinn bei einem Vergleichsprozeß, wie er etwa durch die Funktion ?assgn ausgelöst wird, bei dem die im Muster auftretenden Variablen einen Wert bekommen.

Die Sprache MATCHLESS enthielt daüber hinaus einen Formalismus, um neueMusterfunktionen einzuführen. Mit allen diesen Elemente konnten wesentlich kompliziertere Mustervergleichprozesse beschreiben werden als bis dahin möglich war.

Hewitt hatte für die Streitfrage, ob Ausdrücke deklarativer oderimperativer Art seien (s.S. 100ff), eine neue Lösung bereit: Als die wesentliche Idee von PLANNER betrachtete er 1969 die Dualität vonimperativen und deklarativen Aussagen. So sei etwa ein Satz {\tt (es folgt aus A B)} ein eindeutig deklarativer Satz, d.h. eine Aussage über einen Fakt. Dieser Satz könne jedoch -- in PLANNER -- auch imperativ verwendet werden, z.B. dazu, da\sseine Prozedur eingeführt werden sollte, die zu prüfen habe, ob A schon angenommen werden darf, und, falls das so ist, die Aufnahme von Bveranlassen sollte. Außerdem könne der Satz die Einführung einer Prozedur veranlassen, die dann, wenn es je das Ziel sein sollte, B zu deduzieren,nahelege, als Unterziel die Deduktion von A vorzunehmen ([HEW69], S. 295).

So wird also der Satz, der dem Muster (implies \$\_\_A \$\_\_B)entspricht, in zwei imperativen Formen benutzt: Als Consequent-Theorem, das für die Aufstellung von Zielen benutzt werden kann (rückwärtsgerichtete Deduktion (engl. backward chaining): Um b zu deduzieren, wird versucht, A zu deduzieren) und als Antecedent-Theorem, das benutzt werden kann,Konsequenzen aus der Tatsache abzuleiten, da\ssein gewisser Satz angenommenworden ist (vorwärtsgerichtete Deduktion (engl. forward chaining): aus A wird B deduziert).

Bei der Aufstellung von Zielen wird mit der Datenbasis gearbeitet. Dabei wird meist zunächst versucht, Fakten zu finden, die ein zu beweisendes Theorem direkt bestätigen (im Ideallfall das bereits früher akeptierte Theorem selbst) oder Theoreme, die das zu beweisende Theorem implizieren.

Da den Theoremen in PLANNER Prozeduren entsprechen, werden diese aktiviert,wenn sie zur Erreichung des Zieles tauglich erscheinen. Der Programmierer erstellt ein System von Theoremen, die mit den PLANNER-Funktionen die Suchenach den benutzbaren Theoremen oder Fakten steuern. Weil diese Suche meist bezüglich eines durch Muster beschriebenen Zieles durchgeführt wird, spricht man von mustergesteuerter Prozeduraktivierung (pattern directed procedureinvocation).

``PLANNER wurde entworfen, um in Situationen zu helfen, wo man eine großeZahl von verknüpften Prozeduren (Theoremen) hat, die beim Lösen eines Problems nach einem allgemeinen Lösungsplan von Nutzen sein könnten. Die Sprache hilft, Prozeduren auszuwählen, den Plan zu verbessern und durch die Prozeduren in einer flexiblen Weise hindurchzugehen, selbst wenn nicht alles genau nach dem ursprünglichen Plan abläuft...'' [HEW69][S.301].

Die für das Beweisen von Sätzen geschaffenen Funktionen und die Möglichkeiten, mit ihnen die Beweisrichtung zu steuern, machten das logische Deduktionssystem von PLANNER in höheren Maße anwendungsbereit undanpassungsfähig als die zeitgenössischen Resolutionssysteme\footnote{Dies betrifft nicht die Beweisgeschwindigkeit.}.

Der hierarchische Kontrollmechanismus, der sowohl durch die Sprache selbst benutzt wird als auch dem Benutzer effektiv zur Verfügung steht, ist wesentliche Basis des deduktiven Systems. Historisch interessant ist, da\ssHewitt in [HEW69] kaum die Backtracking-Mechanismen hervorhebt, sondernauf die starke Rekursivität der Sprachimplementation Wert legt. Hervorzuheben ist dabei (an dieser und an allen späteren Arbeiten Hewitts überPLANNER), da\ssGedanken über die mögliche Implementation eine große Rollenspielen, obwohl nur eine einzige wirkliche Implementationen einer Teilsprache in näherer Umgebung von Hewitt durchgeführt wurde.

1970 hatten G.J.Sussman und E.Charniak für T. Winograd innerhalb von 14 Tagen MICROPLANNER implementiert, wie dieser Teil von PLANNER nun genannt wurde [SUS70]. Nach ersten Erfahrungen wurde dieser Übersetzer durch die drei Autoren unter Mithilfe von {\sc D.V.McDermott, C.Reeve, B.Daniels, G.Benedict} und G.Peskin weiterentwickelt [SUS72]\footnote{Vgl. auch Hewitts Beitrag in [AD73}.]). In [HEW 71b] spricht Hewitt von mehreren Untersprachen, die amMIT implementiert worden seien\footnote {die Sprache MDL (auf sie verweist Hewitt}). und da\ssdiese Arbeiten im MULTICS-LISP und im ITS-LISP (d.h.LISP1.6) vorgenommen worden seien. Allerdings ist dies der einzige Hinweis auf weitere Implementationen. MICROPLANNER wurde auch in dasSTANFORD LISP1.6 übernommen und leicht verändert [BAUM72].

MICROPLANNER enthält alle wesentlichen Ideen von PLANNER, ist aber,insbesondere beim Mustervergleich, einigen starken Einschränkungen unterworfen. Analysiert man die vorhandenen Beschreibungen, so ergibt sich etwa folgendes Bild: Es wird mit zwei hauptsächlichen Objekten gearbeitet -- mit Assertions und mit Theoremen. Assertions sind geordnete Tupel von nichtnumerischen Objekten, die als Aussagen über Fakten interpretiert werden können. Die Theoremen entsprechen den Prozeduren in anderen Programmiersprachen; sie enthalten aber zusätzlich einen Informationsteil, der Aussagen darüber macht, wann das Theorem benutzt werden sollte und welche Art von Veränderungen das erfolgreich benutzte Theorem in der Datenbasis der Assertions hervorruft.

Sowohl Assertions als auch Theoreme können dynamisch erzeugt oder modifiziert werden durch arbeitende Programme. Als interpretative Sprache ist MICROPLANNER mit einer Reihe von Mitteln zur Strukturierung derProgramme ausgerüstet; der Interpreter enthält Teile, die die Arbeit der Variablenbindung, der Behandlung von Zustandsbeschreibungen (Kontrolle im normalen Sinne, aber auch das Retten und Wiederherstellung im Backtrack-Fall) erledigen. Diese allgemeinen Möglichkeiten sind nicht durch den Benutzer direkt manipulierbar. Das System führt nicht nur die Einrichtung von Entscheidungspunkten aus, sondern erledigt auch die Wiederherstellung der Umgebung in diesem Punkt, wenn das Programm dorthin zurück muß. Diesen Vorgang kann der Benutzer durch abbrechen eines Programmzweiges selbst auslösen.

Gegenüber der umfangreichen Musterformulierungssprache MATCHLESS in[HEW71c] ist der Beschreibungsformalismus für Muster in MICROPLANNER starkeingeschränkt. Es gibt nur zwei Variablentypen (Präfix \$? und \$$\leftarrow$)\footnote {\$$\leftarrow$ erlaubt Wertänderung, \$? einmalige Wertzuweisung.}, die nur im obersten Niveau des Musters auftreten dürfen. Muster werden nur mit Behauptungen (Assertions) verglichen.

Der deduktive Mechanismus benutzt drei Arten von Theoremen, die Consequent-, Antecedent- und Erase-Theoreme. Entsprechend PLANNERlösen die Consequent-Theoreme eine Unterzielaufstellung aus, so da\ssder Beweisverlauf als Rückwärtsverkettung dargestellt werden kann. Mit den Antecedent-Theoremen sollen bestimmte Behauptungen so früh wie möglich abgeleitet und in die Datenbasis aufgenommen werden. Wenn z.B. eine Änderung der Datenbasis durch Hinzufügung neuer Assertions festgestellt wird, {\tt

(THASSERT (HUMAN SOCRATES))
(THASSERT (GREEK SOCRATES))
(THASSERT (HUMAN NEWTON))
(THCONSE (X) \=(FALLIBLE \$?X)
 	       (THGOAL(HUMAN \$?X)))
(THPROG \=(X)
   (THGOAL  (FALLIBLE \$?X)\$T)
   (THGOAL  (GREEK \$?X))
   (THRETURN \$?X))

}\begin{center}Abb. 15. Ein MICROPLANNER-Beispielprogramm [SUS71][S.5]\end{center}

dann wird versucht, mit den Antecedent-Theoremen weitere Assertions abzuleiten. Bei dieser Vorwärtsverkettung besteht die Gefahr, da\ssdie Datenbasis mit einer großen Zahl unnötiger Faktenaussagen (Behauptungen, Assertions) aufgebläht wird.

MICROPLANNER wurde in viele LISP-Systeme übernommen. Dabei scheinenallerdings wenig wirkliche Anwendungen zu sein [LAU75]. Etwa zur selben Zeit,teilweise in direkter Diskussion und Zusammenarbeit, entwickelte sich das Metasystem QA4.

 

QA4

Etwa 1967 begann C.C.Green mit der Arbeit dem Frage-Antwort-System QA1 beider Systems Development Corporation. Dieses System sollte eine Weiterentwicklung des Raphaelschen SIR [RA63] sein und wurde für das Q-32-LISP programmiert.Green setzte gemeinsam mit Yates die Arbeit am SRI fort (dortexistierte eine SDS940 mit BBN-LISP). Gemeinsam entwickelten sie eine neue Version: QA2.

Als Green seine Promotionsarbeit Mitte 1969 an der Stanford Universityvorlegte, war aus dem System ein Resolutionsbeweiser geworden, der um sich herum Fähigkeiten zur Arbeit mit einer Datenbasis gruppiert hatte [GRC69a,GRC69b].

Dieses Frage-Antwort-System diente dann als Ausgangspunkt für eine neue Entwicklung zu einer einsatzfähigen Basis für die Programmierung in Bereichen der Künstlichen Intelligenz. Man hoffte, zu einer Sprache zu gelangen, die natürlicher sein sollte als der Prädikatenkalkül 1. Ordnung und die die Hintergrundsprache eines Theorembeweisers sein könnte, der Beweise lieferte, die man als intuitiv und durch die Semantik des Problems bestimmt akzeptieren könnte. Da das normale LISP hier zu viele Beschränkungen zu enthalten schien, wurde Schritt für Schritt eine neue Sprache geschaffen, die, weil das Ausgangssystem QA3 hieß, QA4 genannt wurde [RUL70].

Die Entwicklung von QA4 wurde zunächst mit handsimulierten Beispielenvorangetrieben; diese Beispiele stammten aus den interessierenden Bereichen automatische Programmsynthese, Roboterplanung bzw. Theorembeweis. Schon bald war eine Sprache geschaffen, die sich in manchen Punkten von den syntaktischen Strukturen der LISP-Ausdrücke unterschied. Später hat man diese Form wieder zurückgenommen. Neben Entscheidungen zur äußeren Form sind schon früh solche in Bezug auf die Datentypen gefallen. Eine Folge dieses Ansatzes war die Bestimmung, da\ssalle Funktionen in QA4 nur ein Argument haben.

Der Zustand von Ende 1970 läßt sich gut an dem Beitrag der Autoren zum IFIP-Kongre\ss[RUL71] ablesen. Neben den einfachen Datenstrukturen, wie Zahlen,Boolesche Werte und literale Atome, sind Mengen, Ballen und Tupel\footnote{Menge (set): jedes Element ist nur einmal vertreten, die Reihenfolge ist uninteressant. Ballen (bag): Elemente können mehrfachauftreten, die Reihenfolge ist uninteressant. Tupel (tuple): dieReihenfolge ist wichtig, d.h. mehrfaches Auftreten ist bedeutsam.} neu eingeführt. Da beim Aufruf der Funktionen ein Mustervergleich stattfindet, kann man durch Forderung eines Ballens beispielsweise die Kommutativität der Funktion ausdrücken.

Durch Mustervergleich beim Funktionsaufruf ist es weiterhin möglich, die Eignung von Argumenten für bestimmte Funktionen zu prüfen. Durch Typen von Mustervariablen (z.B. Fragmentvariable, die einen ganzen Argumentteil zugeordnet bekommen kann) und Forderungen bezüglich Typ oder Wert sowie durch die Suche nach vorgegebenen Elementen in dem zu prüfenden Ausdruck, können die Argumentkomplexe auf lokale Variable aufgeteilt werden.

Der Mustervergleich wird auch für Fragen an die Datenbasis, für die Aktivierung von Strategien und Folgerungsregeln eingesetzt. Diese Strategien werden benutzt, um beispielsweise eine gewisse parallele Abarbeitung der Programme durchzuführen.

Neben dieser parallelen Abarbeitung bot QA4 die üblicheHintereinanderausführung von Anweisungen, gewisse iterative Sprachelemente für die Verarbeitung von Datentypen und automatisches Backtracking\footnote{das z.B. ausgelöst wird, wenn eine Funktion unpassende Argumente bekommt.}.

Der Speicher ist als Diskriminationsnetz organisiert. Jeder Ausdruck existiert nur einmal, da er auf eine kanonische Normalform zurückgeführt wird.

QA4 enthielt noch vor CONNIVER (s.S. 298) einen Kontextmechanismus. EinKontext stellt eine Gesamtheit von Variablenbindungen dar. Durch die besondere Darstellung der Ausdrücke in QA4 war es möglich, ihnen auchEigenschaftslisten zuzuordnen. So umfaßt der Begriff des Kontext nicht nur die Bindungsbereiche von Variablen, sondern auch Eigenschaftsbereiche: Ein Ausdruck kann verschiedene Eigenschaften in verschiedenen Kontexten bei einem Indikator haben.

Wie die meisten anderen LISP-Systeme und Metasysteme ist auch QA4 einGemeinschaftswerk vieler Autoren und beeinflußt durch Diskussionspartner in vielen Fortschungzentren. So hat neben Deutsch, A. Kay, Sandewallund einer Reihe von Anwendern (unter ihnen {\sc R.Fikes, P.Hart, N.Nilsson, I.Greif}) auch Hewitt manchen Vorschlag für die Weiterentwicklungbeigesteuert.

Nach eingehenden Diskussionen der QA4-Entwickler mit {\sc Hewitt, Sandewall,Kay} und Deutsch wurde Mitte 1972 die endgültige Version erreicht [RUL72].

Die wesentlichen Eigenschaften des Systems haben sich nicht geändert. Allerdings war man wieder zu einer Quellsprache übergegangen, die dem normalen LISP recht ähnlich ist. Nur bei der Präfixnotation für Mustervariable existieren ins Auge fallende syntaktische Unterschiede zu den S-Ausdrücken.

QA4 ist wie LISP eine Ausdruckssprache. Die Ausdrücke werden aus einfachenElementen wie Namen, Zahlen, Wahrheitswerte, Mengen, Ballen und Tupel aufgebaut. Ausdrücke der Form (function Argument) heißen Anwendungen.Generell tritt nur ein Argument auf, aber aus Bequemlichkeitsgründen darf statt eines Arguments vom Typ Tupel direkt die Folge der Tupelelemente notiert werden.

{\tt

[TUR\=NONLIGHT (LAMBDA (STATUS $\leftarrow$M ON)\+
(PROG \=(DECLARE N)\+
(EXISTS (TYPE \$M LICHTSWITCH))
(EXISTS (TYPE $\leftarrow$N BOX))
(GOAL \$DO (NEXTTO \$N \$M))
(GOAL \$DO (ON ROBOT BOX1))
(\$DELETE (QUOTE (STATUS \$M OFF)))
(ASSERT (STATUS \$M ON))
(\$BUILD ('(:STURNONLIGHT ACTION \$M]

}\begin{center}Abb. 4.16. Ein QA4-Beispielprogramm [RUL72][S.295]\end{center}

Der Bindungsmechanismus in QA4 ist grundsätzlich durch Mustervergleichgesteuert. Statt der Variablenliste wird das Muster angegeben, in dem dann die Variablen auftauchen. Entsprechend ihrer Funktion in dem Mustervergleichsprozeß, der dem Bindungsproze\ssin LISP entspricht, sind dieVariablen mit Präfixen gekennzeichnet. Dabei entspricht der Präfix \$ einerBezugnahme auf den Wert der Variablen, der Präfix $\leftarrow$ einer möglichen Zuweisung und der Präfix ? stellt eine Zwischenstufe dar: Hat die Variableschon einen Wert, dann wird dieser genommen, hat sie noch keinen, dann wird zugewiesen. Doppelte Präfixe bezeichnen Fragmentvariablen, die also etwastatt einem Mengenelement der Restmenge oder statt einem Tupelelement einem Tupelstück entsprechen.

An Funktionen steht eine gewisse Menge von eingebauten Standardfunktionen sowie Spezialformen (z.B. PROG) zur Verfügung. Der Nutzer kann aber neueFunktionen definieren.

Die Bindungsoperation beim Eintritt in eine Funktion, die, wie bereits gesagt wurde, einen Mustervergleichsproze\ssbeinhaltet, kann beim Versagen desVergleichs ein Backtracking auslösen. Dies gilt dann, wenn alle Bindungsmöglichkeiten erschöpft sind oder die Muster überhaupt nur eine Möglichkeit erlauben. Kann die Bedingungsoperation erfolgreich abgeschlossen werden oder stehen weitere Möglichkeiten offen, dann wird ein Entscheidungspunkt eingerichtet.

Mu\ssbeispielsweise folgende ``Anwendung'' ausgewertet werden

\begin{center}\tt ((LAMBDA (SET $\leftarrow$X $\leftarrow$Y $\leftarrow\leftarrow$ Z) (f \$x \$\$z)) (SET 5 6 7))\end{center}

so gibt es neun Bindungsvarianten, zu denen unter anderen \begin{center} X = 5, Y = 5, Z 0 (SET 6 7) oder

X =5, Y = 6, Z = (SET 7)\end{center} gehören. Ähnlich wie die LAMBDA-Bindung operiert auch die Zuweisung (SETQ)als Mustervergleichsproze\ssmit eventueller Einrichtung vonEntscheidungspunkten. Daneben gibt es mehrere Arten von Ausdrücken (Statements, mit denen der Nutzer explizit solche Punkte aufbauen kann(GOAL, ATTEMPT usw.).

In dem Diskriminationsnetz existiert jeder Ausdruck nur einmal. Den Ausdrücken, die z.B. Faktenaussagen repräsentieren, können, wie in LISP den Atomen, Eigenschaften zugeordnet werden. Diese können direkt mit den Funktionen PUT, GET und ERASE manipuliert werden. Darüber hinaus kann manaber auch generell Anfragen nach der Existenz von Ausdrücken einer gewissen Form (durch Muster beschrieben) mit bestimmten Eigenschaften stellen.

Ähnlich den Bindungsumgebungen von Variablen in LISP kann ein gewisser Zustand des Diskriminationsnetzes mit seinen Ausdrücken und deren Eigenschaften als Bindung betrachtet werden. Der QA4-Name dafür istKontext. Ein neues Kontext-Niveau wird immer dann aufgebaut, wenn eineFunktion oder PROG betreten wird. Im Unterschied zu LISP kann sich derNutzer sowohl in den Wertzuweisungen (SETQ) als auch in denPUT-Operationen an P-Listen auf jeden Kontext beziehen, den er auswählenmag. Schließlich kann der Nutzer selbst Kontexte bilden.

Eine durch QA4 wieder aufgegriffene Kontrollstruktur ist derDämon. Hier handelt es sich um eine Funktion, die nur aktiviert wird, wennbestimmte Änderungen in der Datenbasis (in der Eigenschaftsstrukturen gewisser Ausdrücke im Diskriminationsnetz) vorgenommen werden. In QA4 istdazu ein WHEN-Statement zu formulieren:

\begin{center}\em (WHEN Bedingung THEN Aktion)\end{center}.

Die Aktion entspricht einem Funktionsaufruf. In der Bedingung können die Änderungen (Zugriff mit GET -- Schlüsselwort SENDS, Zuweisung mit PUT--Schlüsselwort RECEIVES usw.) sowie die Stelle, an der diese Änderungenvorkommen (Wert bzw. Eigenschaft) und als auch einschränkende Angaben der interessierenden Änderungswerte angegeben werden.

Es würde zu weit führen, wenn alle neuen Ideen, die in QA4 eingeflossenwaren, hier besprochen würden. Sicher ist, da\ssQA4 einen Markstein in derBewältigung von Programmierproblemen auf dem Gebiet der Künstlichen Intelligenz darstellt.

In der wirklichen Anwendung war QA4 nicht ganz so durchschlagend, wie esnach der zukunftsträchtigen Konzeption den Anschein haben mag. Da ist aber ein typisches Problem bei der Entwicklung von LISP-Metasystemen: Die Techniken, um ein solches System aufzubauen, sind recht einfach zu handhaben. Die Verarbeitung innerhalb des Metasystems läuft aber etwas langsam ab, da meist doppelt interpretiert wird. So ergeben sich Effizienzprobleme. Häufig liegen nach kurzer Anwendungszeit wieder soviel neue Ideen vor, da\ssdas alte System ohne Bedauern vergessen wird. Ursache für dieses Vorgehen ist der zeitweise stürmische Fortschritt der Wissenschaft von der künstlichen Intelligenz.

 

MLISP2

In den Jahren 1971-72 erreichten die Metasysteme am SRI und an der Standford University ihre endgültige Version. Sie sind beide dadurch charakterisiert, da\sssie bis zum Ende als Metasysteme angesehen werden können.

An der Stanford University wurde MLISP recht häufig benutzt, so da\ssdieImplementatoren, Enea und Smith, Sinn in einer Weiterentwicklungsahen. Sie betonten dabei die Compiler-Compiler-Linie unter Berücksichtigung der neuen, mit PLANNER und QA4 entwickelten Ideen.

Die Verwendung vom MLISP hatte nahegelegt, da\sses wünchenswert wäre, dieSyntax von MLISP so zu gestalten, da\sssie leichter geändert werden kann.Dadurch wäre es möglich, auch Programme in den verschiedenen, sich äußerlich recht ähnlich sehenden LISP-Metasystemen zu akzeptieren. Die Erfahrungen mit der Umsetzung einer bequemen Programmiersprache in die intern so nützliche und wirksame LISP-Struktur führte zu dem Ziel, ein Metasystem zu schaffen, das es ermöglichen könnte, beliebige andere Programmiersprachen auf die gleiche Art zu behandeln. Die von LISP her naheliegende Syntaxanalysemethode der Top-Down-Analyse wurde um Backtracking verstärkt, um die Klasse der verarbeitbaren Sprachen zu vergrößern.

Durch das Vorbild von PLANNER hatten die Autoren die Möglichkeit, sich mitaktuellen Implementationen des Backtracking auseinanderzusetzen. Sie kamen zu einer eigenständigen effizienten Lösung.

Smith und Enea schlossen die Arbeit an MLISP2 etwa 1971 -- 1972 ab. Inder Hauptinformationsquelle [SM73a] berichteten sie von einem seit über zweiJahre arbeitenden System.

MLISP2 wird in [SM73a] vor allem als Basissystem zum Schreiben vonÜbersetzern bezeichnet. Es sei durch folgende Eigenschaften gekennzeichnet: Die Notation von MLISP, die Erweiterbarkeit der Sprache (die nicht nurMLISP2 betraf, sondern ermöglichte, neue Sprachen zu definieren), derMustervergleich (pattern matching) und das Backtracking.

MLISP ist in vielen Beziehungen als aufwärts kompatibel zu MLISP2anzusehen; die hauptsächlichen Änderungen modifizieren nicht die Syntax der Sprache, sondern die Kontrollstruktur oder das Ausführungssystem (execution environment) von MLISP, so da\ssdie Anwendungsmöglichkeiten wesentlicherweitert werden. Einige kleinere Änderungen\footnote{Beseitigung von BEGIN-END-Klammern [SM73a][S.12]; Zulässigkeit beliebiger Zahlen vonQualifikatoren nach einem Basisausdruck, d.h. wiederholte Betrachtung des Resultats einer Funktionsanwendung als Funktion und Argument derselben [SM73a][S.182]; eine bequeme Notation für die P-Listenverarbeitung -- diePunktnotation [SM73a][S.20], Unzulässigkeit von Vektorzuweisungen[SM73a}[S.18].] sollen die Sprache in ihrer Lesbarkeit verbessern.

Die ``großen'' Änderungen im Vergleich zu MLISP werden durch die AusdrückeLET und SELECT verkörpert.

Der LET-Ausdruck vereinigt einen Syntaxmustervergleicher (syntactic patternmatcher) und einen semantischen Ausdrucksauswerter. Er kann benutzt werden, um die Sprache zu erweitern, völlig neue Sprachen zu definieren oder um in beliebigen Zusammenhängen als Mustervergleicher zu dienen. In gewissen Sinne ist er das Herz des MLISP2-Erweiterungsmechanismus [SM73a][S.24].

Allerdings stellt die Auffassung von der Anwendbarkeit des Mustervergleichs und seiner Aufnahme in MLISP2 eine Einschränkung gegenüber denMöglichkeiten etwa in PLANNER dar: In MLISP2 ist der Mustervergleicher nurfür die Verarbeitung von linearen Eingabedaten (Zeichenfolgen) gedacht, denn er soll hauptsächlich als Hilfsmittel zur Übersetzerkonstruktion eingesetzt werden.

Die Muster, die in einem LET-Ausdruck angegeben werden können, können ineiner Notation formuliert werden, die man berechtigt als Syntaxbeschreibungssprache bezeichnet kann. Diese besteht aus vierGrundkonstruktionen (Literale, Nichtterminale, Inline-Ausdrücke und Metaausdrücke) und gewissen zusätzlichen Elementen. Die Autoren waren der Ansicht, da\sssie mit ihren Ansatz jede kontextfreie oder kontexsensitiveGrammatik beschreiben können. Dazu dient die Möglichkeit, während der Verarbeitung einer Sprache die Grammatik ändern zu können.

Der auf dieser Beschreibungssprache aufbauende Verarbeitungsmechanismus gewann seine Potenz aus dem Mustervergleicher und den im ihn eingebauten Backtrackingmöglichkeiten. Alle drei Metaausdrücke\footnote {REP}-Wiederholung, ALT -- Alternative, OPT -- für wahlweises Element.führen bei ihrer Abarbeitung während des Mustervergleichs zur Einrichtung von Entscheidungspunkten, zu denen im Irrtumsfall zurückgegangen werden kann [SM73a][S.36ff].

Charakteristisch bei der Spracherweiterung bzw. -beschreibung mittels LET-Ausdruck ist die Tatsache, da\ssdie Syntaxregeln, die als Musterangegeben werden, sofort in LISP-Programme umgesetzt und compiliert werden, während die semantischen Routinen in LISP-Ausdrücke umgesetzt bleiben [SM73a][S.26,77].

Das in MLISP implementierte Backtracking spiegelt sich hauptsächlich imSELECT-Ausdruck wider -- wenn man die impliziten ELemente innerhalb desMustervergleichers nun beseite läßt.

SELECT stellt eine Verallgemeinerung der Floydschen WahlfunktionCHOICE dar [SM73a][S.50], [SM73b]). Der SELECT-Ausdruck benötigt fünfAngaben für die Ausführung von Teilaktionen, die, falls ausgelassen, durch Standardinformationen ersetzt werden. Diese Angaben sind: Eine Wertfunktion, ein Bereich, aus dem ausgewählt werden soll, eine Nachfolgerfunktion (Bestimmung des nächsten Elements), eine Endebedingung und schließlich eine Endefunktion. Diese Funktionen werden durch Ausdrücke repräsentiert, die gewissermaßen die LAMBDA-Körper darstellen [SM73a][S.50]. Wird die Terminationsbedingung erfüllt, so wird die Terminationsfunktion auf den Wertebereich angewendet. Dabei kann es vorkommen, da\ssmit der Funktion FAILURE ein Backtracking explizitausgelöst wird, das zu dem durch SELECT eingerichteten Entscheidungspunktzurückführt [SM73a][S.49ff].

MLISP2 bietet dem Nutzer reines Datenbacktracking [SM73a][S.?] wobei der Rückgang zu einem Entscheidungspunkt zu einer Wiederherstellung der Variablenwerte an diesem Punkte führt \cite[SM73b]. Die Implementation folgt dabei einer sehr effizienten Strategie; für den Benutzer ist die Grundphilosophie einfach, plausibel und durchschaubar.

Die hervorragenden Eigenschaften von MLISP2 führten zur Implementationeiner ganzen Reihe bekannter und wichtiger Sprachverarbeitungssysteme, unter denen Milners Implementation von D.Scotts Logik für berechenbareFunktionen die folgenreichste gewesen ist [MIL72a]. Daneben mu\ssaber einDeduktionssystem [WEY74], ein Parser für Englisch, einEnglisch-Französisch-Übersetzer, ein ALGOL-Compiler und MLISP2 selbsterwähnt werden [SM73b][S.680]; nicht zu vergessen ferner denPascal-LISP-Umsetzer von R.L.London und D.C.Luckham [IG73].

Den nächsten Schritt sollte das Metasystem LISP70 darstellen. Man hofftedurch Vervollkommung der verfügbaren Kontrollstrukturen ({\em backtrack and coroutine control structur}) und Erweiterung der Datenmanipulationsmöglichkeiten ({\em pattern matching, streaming, long-term memory for large data bases, data typing, pattern directed computation}) eine neue Qualität von Basissystem für Arbeiten der Künstlichen Intelligenz erreichen.

Nach den Berichten [SM73a][S.2],[TES73] ist eine erste Version vonLISP70 im Juni 1973 gelaufen, jedoch eine wirkliche (production) Versionwar noch nicht und ist niemals vollständig implementiert worden.

Interessant an LISP70 ist, da\ssseine Autoren in gewissem Sinne wieder andie Erarbeitung eines LISP-Nachfolgers dachten. Dabei haben sie so manche Eigenschaften des erfolglosen LISP2 wieder aufleben lassen: Die Vereinigung von LISP1.5 und ALGOL in Syntax und Sematik [TES73][S.671], dieCompilierung aller Funktionen usw.

Die grundlegende Philosophie von LISP70 geht von einem erweiterbarenSprachkern aus, den der Nutzer durch Definieren neuer Hilfsmittel ausbauen und durch Einbau effizienterer Implementationselemente für oft benutzte Teile der Sprache verändern kann. Für diese Veränderbarkeit in Richtung auf Erweiterung und Spezialisierung benutzten die Autoren eine maschinenunabhängige Sprache niederen Niveaus (Code für eine ideale LISP-Maschine [TES73][S.671]), um die Transferierbarkeit der Sprache zusichern.

So liefert der LISP70-Compiler Programme in dieser Sprache ML, dieanschließend in Objektcode übersetzt werden müssen. Nur der letzte Teil ist maschinenabhängig. Der Compiler ist Teil der Funktion EVAL -- jedesArgument von EVAL wird compiliert bezüglich der aktuellen Umgebung und dann als Maschinencode ausgeführt. Dazu sind Teile der Symboltabellen und der ganze Compiler ständig im System präsent.

Die Forderung bezüglich Effizienz sollen durch einen besonders schnellen musterbasierten Übersetzer erfüllt werden, dessen Regeln in kurzen und effizienten Code compiliert werden.

Ebenso wie LISP2 verschwand das ``LISP für die 70er Jahre'' allerdingsrecht schnell von der Bühne. Die Gründe hierfür scheinen im Wechsel der Autoren von der Stanford University zu anderen Arbeitsplätzen zu liegen.

MLISP2 wurde nur kurze Zeit zum bequemen Schreiben von Übersetzern benutzt. Auf Grund der doppelten Interpretation (MLISP2-Programme werden in LISP umgesetzt und durch ein speziellesVerarbeitungsprogramm interpretiert, das seinerseits im LISP-System abgearbeitet wird) werden zu große Verarbeitungszeiten registriert. Obwohl die Reports [SM73a,TES73] beinahe überall unter LISP-Benutzern bekannt sind,ist doch das System nie exportiert worden. So blieb der Nutzerkreis ganz klein und lokal.

LET PATTERN (L) =
    { {REP 1 M * {
             {OPT '!}
             {OPT '#}
             {ALT [IDENTIFIER]
                   | '[TOKEN]
                   | '< [IDENTIFIER] !'>
                   | '[  !']
                   |    

}}} } MEAN L;

 

\begin{center}Abb. 17. Ein MLISP2-Beispielprogramm [SM73a][S.78]\end{center}

 

Von PLANNER zu CONNIVER

Bei der Implementation und Anwendung von MICROPLANNER konnte das Verhaltender Programmierer und ihre Probleme studiert werden. Schnell wurde klar, da\ssnoch manches zu wünschen übrig blieb. Dies galt insbesondere in Bezug die Effizienz.

Selbst Hewitt hat zugegeben, da\ssdie PLANNER-Prozeduren genuinuneffizient sind [HEW71b][S.21]. Sussman und McDermott alsImplementatoren kamen zu dem Schluß, da\ssvor allem das automatischeBacktracking Schuld ist, weil es zu schlechten Programmierpraktiken verleite [SUS72a][S.7]. Ihre Hauptthese ist dabei, da\ssdie wesentlichenTeile der Kontrollstrukturen, Backtracking und Multiprocessing, nur dem schlechten Programmierer dienten -- der gute käme auch ohne sie aus [HEW71b][S.13].

Auf Grund ihres Studium von PLANNER und des Gebrauchs von MICROPLANNERentwickelten Mcdermott und Sussman eine eigene Sprache, die sieCONNIVER nannten [SUS72b,MCD72].

Obwohl sich die Kritik von Sussman und McDermott vornehmlich gegen dasBacktracking richtet, kann man doch leicht erkennen, da\sssie sich inWirklichkeit gegen das eigentliche Konzept von PLANNER wenden. Nichtzufällig drücken sie ja auch in dem Titel ihrer Streitschrift aus: ``Conniving ist better than Planning!''. (Sich um nichts kümmern (?) ist besser als Voraussicht.) Der Kern ihrer Analyse ist ohne Zweifel der Satz: ``Was gebraucht wird, ist eine Programmiersprache, und nicht ein Theorembeweiser'' [SUS72a][S.30].

Die beiden Autoren möchten also den Programmierer zwingen, sich seine Programme selbst gut auszudenken und nicht onhe Analyse ein schlecht aufgearbeitetes Problem einem zu allgemeinen Mechanismus aufzuhalsen. Damit wenden sie sich aber zugleich gegen das Prinzip, ein Problem nicht durch ein selbstentwickeltes Programm zu behandeln, sondern es zu beschreiben und das System mit Hilfe dieser Beschreibung die Lösung finden zu lassen. Insofern hat Hewitt auch recht, wenn er [HEW75a] Hayes zitiert, der feststellt,da\sshier ein Schritt zurück gemacht wurde (``... something of a retrogradestep ... [HEW75a][S.190].

Dennoch stellt CONNIVER eine interessante Entwicklung dar. Wie MICROPLANNERliegt CONNIVER als interpretierte Sprache vor, das Vearbeitungssystem wurde in LISP geschrieben.

CONNIVER benutzt, ausgehend von einem Implementationsmodell von Bobrow und Wegbreit[BO73c], neben dem Baum von Kontrollinformationen (control environments) noch einen Datenbasenbaum,der Kontextbaum genannt wird. Der Nutzer hat es immer nur mit dem letzten Zweigdieses Baumes zu tun: Jede Änderung betrifft nur die Daten im gerade aktuellen Zweig. Er kann leicht die Kontexte wechseln, um etwa lokale Imformationen zu einem äußeren Kontext zu übergeben.

Jeder Anwender kann seine Kontrollstrukturen selbst aufbauen; dadurch soll erreicht werden, da\sser sich über den Ablauf mehr Gedanken machen muß. Neu imUnterschied zu PLANNER ist, da\ssdie prozedurähnlichen Gebilde, die denTheoremen von PLANNER entsprechen, hier Methoden genannt, beimMustervergleich nicht mit dem ersten (bzw. nächsten) Element aus der Datenbasis arbeiten, sondern eine Liste der Moglichkeiten geliefert bekommen, die sie dann selbst zu verwalten haben. CONNIVER stellt Sprachstrukturenzur Verfügung, in denen diese Arbeit notiert werden kann.

Durch die explizite Form der Verwaltung des Programmablaufs kann der Benutzer von CONNIVER sich jede Art von Ablaufplanung ausdenken undverwirklichen.

Der Mustervergleicher arbeitet mit ähnlichen syntaktischen Strukturen wie MICROPLANNER, ist allerdings in der Lage, beliebig strukturierte Muster zuverarbeiten.

Alle die LISP-fremden Teile in der Syntax, sowohl bei MICROPLANNER als auchbei CONNIVER, sind mit Hilfe der MACRO-Zeichen in MACLISP implementiertworden. Das betreffende Zeichen aktiviert ein LISP-Programm, das eventuell erneut zur Eingabe schreitet und das als Ergebnis die gewünschte interne Struktur liefert. Diese Möglichkeit hat dazu geführt, da\ssin MACLISP meistnur Metasprachen implementiert wurden, die weitgehend LISP-ähnlich in ihrer Syntax sind.

Von PLANNER erhalten geblieben ist in CONNIVER der mustergelenkteProzeduraufruf. Beim Mustervergleich werden in den Möglichkeitenlisten nicht nur Elemente aus der Datenbasis berücksichtigt, die direkt dem Muster entsprechen (items), sondern auch die Methoden, die zu einem solchenpassenden Element führen würden. Wenn der Mechanismus für das Ausprobieren der Möglichkeiten (TRY-NEXT) eine solche Möglichkeit findet, mu\ssdie mitihr verknüpfte Prozedur aktivuert werden.

Der Streit um CONNIVER und PLANNER hat seit 1972 manches Treffen derSpezialisten auf dem Gebiet der Künstlichen Intelligenz belebt. Schon 1971 dürfte es manche harte Auseinandersetzung am MIT gegeben haben.

(IF-NEEDED WINMODES
     (WINMODE? PLAYER? SQUARE? MOVE)
     "AUX" (PLAYER SQUARE MOVE (CONTEXT (PUSH 'CONTEXT))
                                                       P1 SQ1 P2 SQ2)

(ADD '(HAS ,PLAYER ,SQUARE)) (REMOVE '(FREE ,SQUARE)) (CSETQ P1 (FETCH '(HAS ,PLAYER ?SQ1))) :OUTERLOOP (TRY-NEXT P1 '(GO 'END)) (CSETQ P2 (FETCH '(HAS ,PLAYER ?SQ2))) :INNERLOOP (TRY-NEXT P2 '(GO 'OUTERLOOP)) (COND ((AND (LESSP SQ1 SQ2) (CSETQ MOVE (THIRD-IN-ROW SQ1 SQ2)) (PRESENT '(FREE ,MOVE))) (NOTE (INSTANCE))) ) (GO 'INNERLOOP) :END (ADIEU) ).

 

\begin{center}Abb. 18. Ein CONNIVER-Beispielprogramm [SUS72a][S.26]\end{center}

In Hewitts Beitrag zum 2. IJCAI 1971 wird auf diese Kontroversen und dieArbeit zwischen 1970 und 1971 praktisch mit keinem Wort eingegangen. Inzwischen waren die mit PLANNER verbundenen Ideen auf zwei Hauptkomplexe gerichtet:Das Problem der Darstellung von Wissen über die ``reale Umwelt'' in Form von Prozeduren (procedural knowledge representation) -- gegenüber der Faktenspeicherung mittels Daten -- spielt neben der musterorientierten Kontrollstruktur (pattern directed multiprocess backtrack control structure) die Hauptrolle und hat sich als Schlüsselidee für die Weiterentwicklung der Wissenschaft von der Künstlichen Intelligenz erwiesen.

Die Arbeit [HEW71a] gibt gerade in ihrer gerafften Form einen guten Überblick über den Stand der Entwicklung in den Grundideen von PLANNER.

Die These von der prozeduralen Einbettung des Wissens (procedural embedding of knowledge) bedeutet nach Hewitt [HEW71a][S.168] da\ssintellektuelleStrukturen (intellectual structures) analysiert werden sollten durch ihre prozeduralen Anologien. Dies ist etwa in folgender Weise interpretierbar: Beschreibungen sind Prozeduren, die beurteilen, wie gut gewisse Kandidaten diesen Beschreibungen genügen; Muster sind Beschreibungen, die mit Datenkonfigurationen vergleichbar sind. Datentypen sind Muster, die in Deklarationen der erlaubten Bereiche von Prozeduren und Variablen benutzt werden. Allgemeiner: Datentypen haben ihre Analogien in der Form, wie Prozeduren Daten bilden, zerstören, beobachten und transformieren...

``Modelle von Programmen sind Prozeduren für die Definition von Eigenschaften von Prozeduren und für die Verifikationen dieser Eigenschaften... '' [HEW71a][S.168].

Besonders schön wird die These wie folgt veranschaulicht: ``Die prozedurale Analogie einer Zeichnung ist eine Prozedur, die die Zeichnung ausführt'' [HEW71a].

Bei der Ablaufsteuerung soll dem Backtracking ein besonderer Platz eingeräumt werden. Damit ist hier ganz konkret die Rückkehr zu früheren Systemzuständen gemeint. So kann ein Versuch gemacht werden, der das verfügbare Wissen benutzt, und falls er nicht zum Erfolg führt, ist eine Wahl möglich, die auch das Wissen benutzen kann, das bei dem erfolglosen Versuch gesammelt wurde. Die spezielle Art der Implementierung des Backtracking in PLANNERspiegelt sich darin wider, da\ssalle Aktionen schrittweise rückgängig gemachtwerden können: So sei es ebenso leicht möglich ein Programm vorwärts wie rückwarts abzuarbeiten.

Durch das Konzept des Multiprocessing (gleichzeitig existieren mehrere Stellen, wo das Programm aktiv ist -- 1973 natürlich beinahe etwas mehr als Zukunftsmusik) soll die Ablaufsteuerung verbessert werden. Mehrere Mustersuchprozesse durch einen Problemraum werden als gleichzeitig ausgeführt angenommen.

Durch die Orientierung auf die Arbeit mit Muster werden in PLANNER dieAspekte der Arbeit mit Datenstrukturen und der Steuerung dieser Arbeit durch Kontrollstrukturen zusammengefaßt. Die Muster werden bei der Konstruktion und Zerlegung strukturierter Daten verwendet. Die Suche nach den Daten, die einem gegebenen Muster ähnlich sind, erfolgt zunächst direkt nach gespeicherten Daten in der Datenbasis. Zeigt sich bei der Verwendung eines zunächst passenden Datums, da\sses dem weiteren Zwecke nicht entspricht, sowird ein Fehler ausgelöst und zu der Wahlsituation zurückgegangen. Ist die Datenbasis erschöpft (d. h. durchsucht), so wird nach Prozeduren gefahndet, die ähnliche Daten erzeugen. Deshalb müssen Prozeduren nicht nur ihre Arbeit machen, sondern man mu\ssihnen das auch ansehen: Jeder Prozedursollte ein Muster dessen beigeordnet sein, was die Prozedur herzustellen beachsichtigt [HEW71c][S.172].

Mit dem weiteren Fortschritt der PLANNER-Konzeption löste sich Hewittzunehmend von LISP. In seiner Promotionsarbeit, die er 1972 vorlegte, beschrieb er ein System, das nur noch bedingt innerhalb LISP implementierbar war [HEW71c]. Die Mustervergleichssprache MATCHLESS wird in wesentlicherweiterte Form dargestellt. Nicht nur das Spektrum der Variablepräfixe -- mit Wertbenutzung (.), Wertbenutzung falls Wert existiert bzw. Zuweisung (?) und Zuweisung (lokal mit \_, global mit :) -- ist erweitert und verdoppelt (! bezeichnet Segmentorientierung vor dem zweiten Präfix) [HEW71c][S.62], sondern auch das Deklarationsschema für die Variablentypen [HEW71c][S.66].

Die Muster sind in allgemeinen Listen, die Konstanten, Variable, Teilmuster (d.h. Unterlisten), Funktionsaufrufe (sytaktisch mit spitzen Klammern bezeichnet liefern sie Elemente, mit geschweiften Klammern bezeichnet liefern sie Segmente), Vektoren (mit eckigen Klammern begrenzt) und Actorausdrücke enthalten. Für den Zugriff zu Vektorelementen dienen Funktionsaufrufe, die eine Zahl in funktionaler Position haben. Actorausdrücken liefern nicht, wie die Funktionsaufrufe, Werte, d.h. Konstanten, sondern Muster.

Der Begriff des Actors sollte in der weiteren Entwicklung ein erheblichgrößeres Gewicht für die PLANNER-Systeme bekommen als 1971.

Im Laufe der Zeit hat Hewitt versucht, alle einigermaßen prograssiven Ideenin Programmiermethodik und Künstlicher Intelligenz in den PLANNERFormalismus aufzunehmen. So wird der Komplex um PLANNER zu einem System vonVorstellungen über die Grundlagen der Künstlichen Intelligenz, über allgemeine Vorstellungen zur Strukturierung von Programmen und die erforderliche Ausdruckskraft von Programmiersprachen. Dabei hat Hewittzeitweise einen gewissen Eklektisismus offenbart.

Bezeichnend dafür ist etwa seine Arbeit zum 3. IJCAI 1973 in Stanford [HEW73]. Präsentiert wird eine lose Sammlung von Ideen für einen neuenFormalismus: PLANNER73. Obwohl durchaus relevante Konzepte repräsentiertwerden, ist doch gerade diese Arbeit äußerst schwer lesbar und stellt eher ein Gemisch von Werbekampagne für den Actorformalismus, von Lewis-Carolli-Zitaten und bruchstückhaft hingeworfenen Elementen derformalen Sprache dar, noch angereichert mit der in späteren Veröffenlichungen noch heftiger werdenden Polemik gegen Sussman undMcDermott.

Im Rahmen dieses Buches kann nicht näher aud die mit PLANNER73 und PLASMAverknüpften Probleme eingegangen werden. Obwohl nach wie vor ein Gutteil LISP hinter dem Formalismus sichtbar wird, sollte PLANNER73 nicht mehr alsLISP-Metasystem (zu schweigen von der fehlenden Implementation) bezeichnet werden. Trotz der oft merkwürdigen Form der zugeordneten Veröffenlichungen darf die PLANNER-Linie als einflußreicher und zukunftsträchtiger Ansatzbezeichnet werden. Weitere Literatur: [PROM11,LAB12,LAB13,LAB14].