Lecture Notes in Computer Science Edited by G. Goos, Karlsruhe and J. Hartmanis, Ithaca
7 GI Gesellschaft fi3r Informatik e.V.
3. Fachtagung L~ber Programmiersprachen Kiel, 5.-7. M#.rz 1974
Herausgegebenyon Bodo Schlender und Wolfgang Frielinghaus III
Springer-Verlag Berlin. Heidelberg. New York 1974
Editorial Board D. Gries • P, Brinch Hansen • C. Moler G. Seegm~ller • N. Wirth
Professor Dr. Bodo Schlender Institut f~ir Informatik und Praktische Mathematik Universit~t Kiel Wolfgang Frielinghaus Telefunken GmbH Konstanz
AMS Subject Classifications (1970): 00 A10, 02 G 05, 68-02, 68 A05, 68 A10, 6 8 A 2 0 , 6 8 A 3 0 ISBN 3-540-06666-7 Springer-Verlag Berlin • Heidelberg • New York ISBN 0-387-06666-7 Springer-Verlag New York • Heidelberg - Berlin This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically those of translation, reprinting, re-use of illustrations, broadcasting, reproduction by photocopying machine or similar means, and storage in data banks. Under § 54 of the German Copyright Law where copies are made for other than private use, a fee is payable to the publisher, the amount of the fee to be determined by agreement with the publisher. © by Springer-Verlag Berlin - Heidelberg 1974. Library of Congress Catalog Card Number 74-234. Printed in Germany. Offsetprinting and bookbinding: Julius Beltz, Hemsbach/Bergstr.
~orwqrt Unter den Fachtagungen der Gesellschaft f ~
Infermatik
ist dies die dritte, die speziell den Programmiersprachen gewidmet ist. Die Vorg~ngertagungen fanden im M~rz 1971 in MGnchen*) und im M~rz 1972 in SaarbrGcken**) W~hrend die Jahrestagar~en der GI versuchen,
statt.
einen Uberblick
Gber alle wesentlichen Bereiche der Informatik und einen wissenschaftlichen Gedankenaustauseh Fachgebieten zu vermitteln,
zwischen verschiedenen
ist es der Zweck der Fachtagungen,
den wissenschaftlichen Fortschritt
in einem Spezialgebiet
in Vortrag ~md Diskussion der Offentlichkeit Zur Entwicklung des Fachgebietes in r e g e l m ~ i g e n
darzustellen.
ist es einmal netwendig,
Zeitabst~nden Gelegenheit zu geben, ~ber
die letzten wissenschaftlichen Forschungsergebnisse berichten,
zu
zum anderen mGssen Arbeiten aus den Anwendungen
vorgestellt werden k~nnen, um die erforderliche gegenseitige Anregung von Theorie und Praxis Wirklichkeit werden zu lassen. Um eine vernttuftige Gliederung der Tagung zu erm~glichen, ist es zweckm~Big,
dan der Programmausschu~
in der Einladung
zur Anmeldung von Vortr~gen spezielle Schwerpunkte setzt. FGr die gegenw~rtige Fachtagung waren dies die Gebiete Semantik von Progra~miersprachen, Ubersetzerbau, Dialogsprachen und Programmiersprachen fGr Proze~rechner. Der Programmausschu~ war bei der Zusammenstellung programmes b e m ~ t ,
des Tagungs-
diejenigen Vortr~ge auszuw~hlen,
die den
oben genannten Zielen einer Fachtagung am besten entsprachen. Uberdies war es m~glich, eine Reihe von international bekannten Wissenschaftlern zu einftLhrenden Hauptvortr~gen zu gewinnen.
*)
Lecture Notes in Economics and Mathematical Systems, Band 75, Springer-Verlag, Berlin . Heidelberg . New York 1972 **) Gesellschaft fiLr Informatik e.V., Bericht Nr. 4, ver~ffentlicht durch die Gesellschaft fGr Mathematik und Datenverarbeitung mbH, 5205 St. Augustin 1, 1972
IV Dem Programmausschu~
geh~rten an:
VI Erfahrungen mit einem Parser-Generator Chomsky-Grammatiken R. Nollmann
fGr
......................................
114
HAU~TVORTRAG : Structured Programs, Arcadian ~achines and the Burroughs W.T. Wilner
......................................
Struktureinheiten ihre 0bersetzung W. Niegel
B1700
in kontextfreien
133
Sprachen und
........................................
149
ALSI - eine h~here Progrsanniersprache zur Transformation v o n ALGOL 68 - Verbunden in SIMULA-Klassen
U. Kastens
.......................................
162
Interaktives Trace- und Debugging-System ALGOL KIEL X 8 J. Baginski,
H. Seiffert
.........................
173
HAUPTVORTRAG: Some Characteristics to Process Control J.G.P.
Barnes
of RTL/2 and their Relevance
....................................
ProzeBorientierte Funktionen
Programmiersprachen,
G. Koch, V. Kussl
189
Formen und
................................
199
Ein Vergleich von Prozess-Kontroll-Sprachen als Basis fGr den Norm~magsvorschlag einer internationalen ProzeBrechnersprache K.F. Ereuter
.....................................
219
ZUM BEGRIFF DER MODULARIT~T VON PROGPJ~MIERSPRACHEN
H. LANGMAACK
I. Modulares Proqrammieren
Die gegenw~rtige Arbeit schlieBt an Uberlegungen an, die J.B. Dennis in seiner Schrift "Modularity"
[3] angestellt hat. Er hebt dort die folgen-
den Ziele modularen Programmierens hervor: I. Man muS sich yon der Korrektheit eines Programmmoduls
unabhMnqig vom
Kontext in gr~8eren Softwareeinheiten ~berzeugen k~nnen. 2. Man muS Programmmodule ohne Kenntnis ihrer internen Arbeitsweisen zusammensetzen k~nnen. Diese Ziele verk~rpern auch den Begriff der Kontextunabh~n~i~kei~ bei W.E. Boebert
[2] °
In ALGOL-artigen Programmiersprachen
sind es offensichtlich die Proze-
duren, die fHr die Betrachtung als Programmmodule
in Frage kommen. Da-
bei muB man sich abet auf diejenigen Prozeduren beschrMnken,
die keine
nicht lokalen
in einem
(globalen)
Parameter haben,
da ihre Verwendung
Progranmmloduldas Konzept der Modularit~t verletzen w~rde. Lediglich das Auftreten globaler Standardidentifikatoren
darf erlaubt sein, die wir
der Einfachhelt halber zu den Grundgr~Ben der Programmiersprache
hin-
zuz~h!en.
Wir nennen ein Programm modular, wenn in ihm~ nur Prozeduren ohne globale Parameter Verwendung
finden. Nach Dennis ist Modularit~t aber nicht
bloS eine Eigenschaft einzelner Programme,
vielmehr sollte HodularitMt
vor allem als Eigenschaft einer Programmiersprache den. F~r Programmiersprachen
se!bst angesehen wet-
erhebt sich n~mlich die Frage, ob jedes
Programm in ein ~quivalentes modulares Programm der gleichen Sprache
9erwandelt werden kann. Wenn das zutrlfft~ eann wollen wir eine P r o g r ~ miersprache modular nennen.
Bislang ist der Begriff der Modularit~t von Programmiersprachen nicht vo!!st~ndig umrissen. des Begriffs ~quivalenz
noch
Noch h~ngt er yon einer prMzisen Fassung
ab. Die funktiona!e ~quivalenz,
bei der zwei
Programme ~quivalent heiBen, wenn sie das gleiche Ein-Ausgabeverhalten zeigen, ist wenig sinnvo!l.
Denn sonst g~be es zu jedem Programm einer
ALGOL-artigen Programmiersprache ein ~quivalentes prozedurloses, modulates Programm,
also
und jede ALGOL-artige Programmiersprache w~re tri-
vialerweise modular.
Bei der Umwandlung eines Programms in ein ~quivalentes modulares sol!te die Prozedurstruktur
im wesentlichen erhalten bleiben.
Modularit~t
sollte vornehmlich dadurch erzielt werden k~nnen, dab globale Parameter in lokale verwandelt werden. Versierte Programmierer kennen diesen Prozess sehr gut, und oft h6rt man die Meinung, die Verwandlung Parameter sei doch stets m~glich.
in lokale
Auf dabei sich zeigende Probleme weist
bereits Dennis in [3] hin, und wir werden sehen, dab dieser Verwandlung Grenzen gesetzt sind
(Satz 3 und 4).
2. Formale ~quivalenz yon Pro@rammen Um dem Erfordernis nach Erhaltung der Prozedurstruktur entgegenzukomment f~hren wir den Begriff der formalen ~quivalenz ein. Dabei stOtzen wir uns auf die Programmiersprache ALGOL 60, die wir zum Zwecke pr~ziser Formulierungen zu ALGOL 60-P nut unwesentlich modifizieren. gegenOber ALGOL 60 in folgender Weise abgewandelt a) Es sind nur eigentliche Prozeduren,
ALGOL 60-P ist
[5] :
keine Funktionsprozeduren
zuge-
lassen. b) Wertaufruflisten und Spezifikationen c) Es sind nur Identifikatoren
in Prozedurdeklarationen
fehlen.
als aktuelle Parameter in Prozeduran-
weisungen erlaubt. d) Neben begin und end haben wir ein zus~tzliches Paar yon Anweisungsklammern {
}. Sie wirken wie Block-begin und Block-end.
Wir verlangen,
dab alle Prozedurr~mpfe in diese Kiammern eingeschlossen sind, und wir nennen sie in diesem Kontext ~umpfklammern. sie Aufrufklammern.
In anderem Kontext heiSen
Wir benStigen diese Klammern, um originale Program-
me, die der Programmierer geschrieben hat, von Progr~mmen zu unterscheiden, die durch Anwenden der Kopierrege! entstanden sind.
ES d~rfte klar sein, was ein syntaktisches heist dazdiber hinaus kators
formal,
genau ein definierendes
durch zul~ssige
Umbenennung
sehen wir als identisch gezeichnet
angenommen
von Identiflkatoren formales
Programm
[7] ), wenn vern~nftig
an. O.B.d.A. werden,
eines
Formale forma!e
Programme, Programm
Identifikatoren
benannt.
und Hbersetzt
kompilierbar,
leere R~mpfe
werden k~nnen.
{ } das resultierende
Programm,
und K' sei formal.
Sei f(al,~..,a n) eine Prozeduranweisung
die zugeh~rige
Prozedurdeklaration
yon n garantiert
die gleiche
Wir d~rfen
dadurch,
Dabei ~m
~ = ... proc '= ~---,I ÷ formales
der KoDierregel
~
. Die partie!!e
n der aktuellen
(~ ~---~')~ im Haupt-
~ als ausgezeichnet Block,
voraussetzen.
ersetzt wird,
Rumpf
Parameter
} urn 9
~' aus
{ ~ m } yon Parameter
a i ausgetauscht
in ~ zu Aufrufklammern
in ~' geworden.
f(x 1...... X n ) ; ~ { ~ } _ i ; ~ < . i ~ ( a l
proe f(xl,. und~ w
'Xn) ; { ~ } ; ' ' ~
sind Relationen
Programm
E~ yon
nigen Programmen
..... an);...
{
~m
in der Menge
~ heist original,
nur als Rumpfklammern heist die Menge die Ausf~hrung
{
Para-
Dann entsteht
wobei die formalen
aktuellen
sind die Rumpfklammern
Kompilierbarkeit
und formalen
daS f(al, .... a n ) durch einen modifizierten
{ ~ }, einen erzeu~ten
} um
Dann heiBt
; {9 };
Anzahl
x i in { ~ }durch die entsprechenden {
Pro-
von ~ . Sei = proc f(x I ..... x n)
werden°
Ein
wenn nach Ersetzen
sich aus ~ durch Anwenden
meter.
Vor-
sind diejeni-
es von ~', es ergebe programm
Ein 68-
gem, S seines definierenden
wenn
gilt:
als aus-
Vorkommen
wie im ALGOL
Programme
die
hervorgehen,
ist.
kompilierbares
fo!gendes
~ ist. Identifi-
definierende
(oder eigentlich
akzeptiert
{9} durch
~e kompilierbar
sei partiell
darf jedes
ist. Kompi!ierbare
n heist partiell
aller Prozedurr~mpfe
60-P-Programm
auseinander
d.h. verschiedene
jeder Identifikator angewandt
gen, die von einem Kompiler Programm
geh~rt.
sind dutch verschiedene
Bericht
gramm
Vorkommen
von Identlfikatoren
heist kompilierbar
kommens formales
ALGOL
wenn zu jedem Vorkommen
verwendet
""
der formalen
Programme.
wenn die Anweisungsklammern
sind.
FUr ein originales
Ein
{ }in
Programm
:= { ~ ' i ~ - - ~ , } ~. Der A__usfHhrungsbaum T~ yon ~ besteht
in E~xdie h~chstens
ein innerstes
aus denje-
Aufrufklamrnernpaar
besitzen.
Jedes Programm
(jeder Knoten)
K" in TH besitzt h6chstens einen
unmittelbaren Vorg~nger ~'~----H" in E~.
Um zum Begriff der formalen ~quivalenz von Programmen zu gelangen, f~hren wir den Begriff der reduzierten AusfOhrung ein. Wir bilden fHr jedes Programm H' e EH das zugeh6rige Hauptp~ogramm H' durch Streichen m aller Prozedurdeklarationen, wir ersetzen jede verbliebene Prozeduranweisung in H' durch ein Spezialsymbol, z.B. call, und wir nennen das m ........... Ergebnis das reduzierte Hauptpr0gramm Hr y o n Nw
ErH := {~IH'
~
E H}
heiBt die reduzierte Ausf~hrun~, TrK
:= {H$IN'
~ TH}
der reduzierte Ausf~hrungsbaum yon H. Zwei origlnale Programme heiBen nun formal ~quivalent, wenn ihre reduzierten AusfHhrungen bzw. Ausf~hrungsb~ume identisch sind. Damit ist die formale ~quivalenz
zweier
Programm~so eingef~hrt worden, dab sie im wesentlichen gleiche Prozedurstrukturen haben. Ferner gilt der
Satz I: Formal ~quivalente Programme sind auch funktional ~quivalent.
for~.j
Von einem originalen Programm H heigt es, es habe|korrekte Parameter~bergaben,
wenn alle Programme H' E E H bzw. T H Dartiell kompilierbar
sind. H heiBt dar~ber hinaus MakroDroqramm, wenn E H bzw. T H endlich ist. Makroprogramme
sind diejenigen,
grammtechnik
implementiert werden k~nnen.
die mit Makro- oder offeney
der f~r gegebenes originales Programm H entscheidet, Parameter0bergaben
Unterpro-
Es gibt keinen Algorlthmus, ob H formal korrekte
hat bzw. ob H Makroprogramm ist. Wir haben jedoch den
Satz 2: Formale Kquivalenz von Programmen ist invariant gegen~ber den beiden Eigenschaften,
formal korrekte Parameter~bergaben
zu haben bzw.
Makroprogramm zu sein. 3. Die Nichtmodularit~t
yon ALGOL 60-P
Wir wollen nun der Frage nach der Modularit~t von ALGOL 60-P nachgehen. Diese Frage h~ngt sehr eng mit dem Entscheidungsproblem rekte Parameter~bergaben zusammen. bale formale Parameter, lich entscheidbar,
fur formal kor-
F~r ALGOL 60-P-Programme N ohne glo-
d.h. fur die Teilsprache ALGOL 60-P-O, ist n~m-
ob H formal korrekte ParameterHbergaben hat. Wenn
wir nun ein effektives Verfahren h~tten, das jedes originale Programm H in ein formal ~quivalentes modulares verwandelte, dann h~tten wir
auch eine positive LIsung des genannten Entscheidungsproblems
fir
ALGOL 60-P. Daher gilt der manchen Progra~mierer iberraschende Satz 3: Es gibt kein effektives Verfahren, das jedes originale ALGOL60-P-Programm in ein formal iquivalentes modulares der gleichen Sprache verwandelt. Dieser Satz liBt zwar die Nichtmodularitit von ALGOL 60-P vermuten, beweist sie jedoch noch nicht. Dazu missen wir erst ein Programmbeispiel konstruieren, das zu keinem modularen Programm formal Iquivalent ist: ~i = be~in proc M(x,y);{ x(y)}1 proc E(n) ;
{
};
proc L(x,y) ; {pr0c A(n) ; {n(x,M)}; proc ~(~,~) ;{~(~,y)}; L(A,A) ;M(A,A) } ; L (E,M) end
T ,~,);MCA',~')}... ...{...T(~, ...{A' (A') }... T
...{ }... ...{...L( AT('~),~('~I;M(A(v),~.('J))}...
J
5 Knoten, siehe unten ~ > 2
. . . { a (~) (X('~)) } , . .
{~(~(a (u-l) ,M) } . . . ... {M(~,,-1).~
,~ (,>-1))}... ~
T
{M(A',A') }... T {A' (~') }... T
{i' (E,M))...
Knoten
{M(ETM) }... T {E (M~}. °.
{
}...
j
Die Identifikatoren A (v) , A(~)
bezeichnen m o d i f i z i e r t e
zeduren A, A. Der A u s f H h r u n g s b a u m der nat~rlichen
T~I
Zahl ~ existiert ein Knoten,
derart dab der aufsitzende
Kopien der Pro-
ist offenbar unendlich,
T e i l b a u m endlich
und zu je-
z.B . . . . {M(A(~),A(~))}..., ist und eine Tiefe >~ besitzt.
Dann aber kann K1 zu keinem m o d u l a r e n Prograr~m formal ~quivalent
sein.
Satz 4: ALGOL 60-P ist nicht modular.
Dagegen gilt Satz 5: ALGOL
60-P-O ist modular;
jedes orlginale Programm
es gibt ein effektives Verfahren,
in ein formal ~quivalentes
modu!ares
das
verwan-
delt. Das V e r f a h r e n werde Parameter
am Beispiel
~2 demonstriert r u m
dort die g l o b a l e n
a und p der Prozedur q zu eliminieren:
E2 = be~in proc p(x) ; {real a; proc q(y) ; {a:= 2+a;p(q) ;y(p) ;q(y) }; x(q) ;p(x) }; p (p) Im transformierten
end
Programm
formale Begleitparameter
~
haben die Prozeduren
~,~,x,~,q,~,y,~
p und q zus~tzliche
erhalten:
{real a; proc q(U~,~,y,~,~) ; {[/ := 2+~; ~( x(~,~,q,a,p) ; p( p( In P r o z e d u r a n w e i s u n g e n
, ~p,
, ~q,q,~) ; , ,x,~,x) };
, ) end
erhalten forma!e Identifikatoren
aktuellen B e g l e i t p a r a m e t e r
x,~,y,~,
meter a,p. Die aktuellen B e g l e i t p a r a m e t e r tifikatoren
anderer nicht formaler
sind unwichtig und k~nnen irgendwelche
toren sein. A n s c h l i e B e n d w e r d e n
x und y die
q erh~it die aktuellen Begleitpara-
im Rumpf von q
Iden-
lokale Identifika-
a,p durch ~,~
ersetzt.
Wer auf dem Standpunkt stehtlselbst q sei globaler Parameter yon q kann auch diesen Parameter in einen lokalen formalen verwandeln. F~r das
Programmbeispiel K3 = be@in proc q(r); {proc f(x) ;{r(x) }; q(f) ;f(r) }; q (q) end mit dem Aufrufbaum T~3
~3
T
• ..{...
;q(f') ; f' (q) .
}
~
...{...
;q(f") ;f" (f') } . . . . . .
"
T
{q(q) }...
. ...{f' (f') }...
• ..{{(f') }... und d e m globalen
formalen Parameter
unendlich viele Begleitparameter f',f",..,
ben~tigt.
bezeichnen modifizierte
4. Eine modulare Obersprache
transformieren
Kopien der Prozedur
anderen den Vorteil,
kann,
nimmt und der Reihe nach unmittelbar diese Welse wird vermieden,
empfindlich
Xl,...,x n
neue Prozedurdeklara-
schafft, st~ren.
Programmiersprache
die die Einsicht
in
Daher r~hrt der Wunsch, ALGOL 60-P-G zu er-
in ALGOL 60-P-G haben die Form
(~) prQc f (x I .... Xnf);{ Die Identifikatoren
dab man sie
hinter das erste begin setzt. Auf
dab die Kopierregel
ALGOL 60-P zu einer modularen weitern. Prozedurdeklarationen
f.
indem man ihre Prozeduren heraus-
tionen mit neuen Prozeduridentifikatoren das Wirken der Kopierregel
Die Identifikatoren
yon ALGOL 60-P
Modulare Programme haben gegenHber formal ~quivalent
r von f hMtte ein analoges Verfahren
yl,...,ymf
~
};.
heiBen formale Parameter
sind die formalen Parameter
neuer Art,
alter Art.Wenn mf oder nf Null
sind, sch~eiben wir die spitzen bzw. runden Klammern nicht. Alle ~brigen Deklarationen
sehen wie in ALGOL 60-P aus.
Ein Term ist eine endliche
Zeichenreihe,
die nach folgenden Regeln ge-
bildet wird: I. Identifikatoren
sind Terme.
2. Wenn ~ Identifikator auch ~ ein
ist und ~!r.~.,~m, (echter)
Term.
m ~ i, Terme sind, dann ist
~i ist aktueller Parameter neuer
Art. Ein sYntaktisches taktischen ALGOL
ALGOL 6 0 - P - G - P r o g r a m m ~ 60-P-Programm
neue K6pfe der obigen Form wandt vorkommende
entsteht
~' dadurch,
in ~' durch
(~) ersetzt w e r d e n und dab man in K' ange-
Identifikatoren
durch Terme auswechselt.
~brigen Begriffe
!assen sich ohne Schwierigkeit
dehnen.
fur das Wirken der Kopierregel:
Beispiel
nun aus einem syn-
da~ Prozedurk~pfe
Auch a!le
auf ALGOL 60-P-G aus-
~4 = begin proc f(r) ; {f(x) }; proc q(r) ;{q(f) ; f(r) }; q (q) en d
T
; f(q)~z~...
• ..{q(f)
•..
I {q (f) ; f (f)} ...
T
• ..{q(q) }...
T
T •..
{f (f) }.. • • ..{q(f)
}...
T Satz
I und 2 gelten auch fur ALGOL
ALGOL
60-P-G sind nur u n w e s e n t l i c h
60-P-G.
Die Sprachen ALGOL
verschieden,
60-P und
wenn man sich auf Pro-
gramme ohne formale P r o z e d u r a n w e i s u n g e n
beschrMnkt.
liegt in der Methode wie man P r o z e d u r e n
f, die durch formale Prozedur-
anweisungen
(i) aufgerufen w~rden,
mit aktuellen Parametern
In ALGOL 60-P w e r d e n alle aktuellen P a r a m e t e r ~bergeben. ebenfalls
Der U n t e r s c h i e d
In ALGOL 60-P-G w e r d e n die aktuel!en P a r a m e t e r im Moment des Aufrufs ~bergeben,
meter neuer Art
~5 = begin real a; proc q(y);{y(q)};
Aufrufs (i)
proc f(x) ;{r := 2+r; x(f) }; q (f)
T
end
als ob sie bereits
als der P r o z e d u r i d e n t i f i k a t o r
aktueller Parameter eines v o r a n g e g a n g e n e n
(3)
alter Art
w ~ h r e n d die aktue!len Para-
(2) so betrachtet w e r d e n k~nnen,
vorher ~ b e r g e b e n w o r d e n w~ren,
versorgt.
im Moment des Aufrufs
f als
(3) auftrat.
Beispiel:
[ (2) • . . { f < a > ( q )
}..
T
...{a := 2+a; q(f)}...
T Aus der Wirksamkeit der Parameter neuer Art r~hrt der
Satz 6: ALGOL 60-P-G ist modular;
es gibt ein effektives Verfahren,
das
jedes origina!e Programm in ein formal ~quivalentes modulares umwande!t.
Die Anwendung dieses Verfahrens
~
auf Programm 93 liefert
= beqin proc q(r) ; {proc f (x) ; {f-(x) } ; q(f) ; f(r) }; q (q) end
Hier bekommt nur die Prozedur f einen formalen Begleitparameter Art. Der aktuelle Begleitparameter neuer Art yon f i s t wird im Rumpf von f
r durch f e r s e t z t . ~
f neuer
r. AnschlieSend
und ~w sind offensichtlich
formal ~quivalent.
Satz 7: Die in Satz 5 und 6 genannten Verfahren lassendie Eigenschaften einer Prozedur,
formal erreichbar bzw.
Dabei heiBt eine Prozedur ~ 9' in TE existiert, Rumpf einer rekursiv,
formal rekursiv zu sein, invariant.
in 9 formal erreichbar,
falls ein Programm
dessen innerster erzeugter Block modifizierter
(eventuell modifizierten)
falls Programme ~ ' ~ - - ~ "
Kopie von ~ ist. ~
in T~ existieren,
zeugte Bl6cke modif±zierte R~mpfe von Kopien von ~
heiBt formal
deren innerste er-
sind.
Erst die Einbettung yon ALGOL 60-P in die modulare Sprache ALGOL 60-P-G hat einen durchsichtigen Beweis fur die algorithmische Unl~sbarkeit des Makroprogrammproblems n~gt es n ~ l i c h ,
fHr ALGOL 60-P geliefert
[6] . Wegen Satz 2 ge-
in ALGOL 60-P-G Programme ohne Prozedurschachtelungen
zu betrachten. FHr die Teilsprache ALGOL 60-P-F yon ALGOL 60-P-G derjenigen Programme ohne Parameter alter Art gilt aufgrund des in Satz 6 genannten Verfah-
J0
rens
Satz 8: ALGOL 60-P-F ist modular,
den Makrogrammatiken von M.J.
Die ALGOL 60-P-F-Programme ohne Prozedurschachtelungen scher
k~nnen mitlFi-
[4] identifiziert werden. Deshalb sind das Problem der formal
korrekten ParameterSbergaben und das Makroproqrammproblem 60-P-F algorlthmisch
fSr ALGOL
l~sbar. Wei! die belden Sprachen ALGOL 60-P und
ALGOL 60-P-F Jeweils Randmengen yon ALGOL 60-P-G darstellen, wird ihr gegens~tzliches Verhalten verstMndlich.
5. Zur Imp!ementierun~ von ALGOL 60-P-G Nachteilig
fSr die Implementierung von ALGOL 60-P-G ist zun~chst, dab
bel sukzessivem Anwenden der Kopierregel die aktuellen Parameter unvorhersehbar umfangreich werden kOnnen
(siehe ~ ) ,
so daS sie nicht mehr
wie bei ALGOL 60-P in jeweils elner Zelle Platz finden.
Selbst wenn
ganze AusdrScke wie in ALGOL 60 oder Anwelsungen wie in ALGOL 68 als aktuelle Parameter zugelassen sind, kann man sich auf ALGOL 60-P zurSckzlehen,
indem man "dicke" aktuelle Parameter zu RSmpfen parameter-
loser Prozeduren macht und die Parameter selbst durch die zugeh~rigen Prozeduridentifikatoren nicht weiter.
ersetzt.
Dieser Weg fShrt bei ALGOL 60-P-G
Bei geeigneter Verweistechnik
im Laufzeitkel!er
[I] kann
man aber auch hier alle aktuellen Parameter in jeweils einer Zelle unterbringen. GewShnliche und formale Prozeduranweisungen f (al,.--,a n) bzw.
x(a I,.., san )
seien auf folgende Weise in Maschinencode 8bersetzt: UNT
Gew Proz Anw
bzw.
UNT
x
f
) fij'<xi>(fij"<xi>)
xi(fiJ"<xi>)
Yij (fij"<xi >)
gi' (xi)
fij '<xi> (xi)
xi (xl)
Yij (xi)
gi' (Yij)
fij '<xi> (Yij)
xi (Yij)
Yij (Yij)
Bei allen Prozeduranweisungen ~(8),die in Programmen~' des Ausf~hrungsbaums T H eines ALGOL 60-P-G-Programms ~ auftreten k~nnen, haben jetzt die Terme a und 8 offenbar die Gestalt: a = fikJk < fik_lJk_l < ... < f i l J l < g i > > °..>>; 8 = fi'k'J'k'>
; k' >~ O.
Satz 2: F~r al!e Prozeduranweisungen e(B) gilt, dab der unmittelbare Teilterm u.T. des k~rzeren Terms Teilterm des l~ngeren Terms ist. Die Anweisungen e(8) lassen sich somit in Form eines Speicherbandes mit zwei Zustandsk6pfen veranschaulichen, wobei sich mindestens ein Zustandskopf immer am oberen Ende des Speicherbandes befindet. Die Bandinschrift ist hierbei der u.T. des l~ngeren Terms von a und 8.
18
Im linken Zustandskopf befindet sich das Anfangssymbol Zustandskopf das Anfangssymbol
von ~ ,im rechten
von 8 ;z.B. :
rechter Zustandskopf
• fik-lJk-l~''
I linker
ifi'k'J'k' •
Zustandskopf
3.Monadische Programme Wir untersuchen jetzt die monadischen Programme, d.h. solche mit der
Einschr~nkung
B: Bei allen Prozeduranweisungen
s(8) gilt, dab ~ = 8
ist, falls s und 8 formal sind. Diese Forderung bewirkt, dab im Hauptteil von fij(i,j fest) Prozeduranweisungen der Arten xi(Yij) und Yij(xi) nicht erlaubt sind. Mit dieset Einschr~nkung l~Bt sich f~r die Prozeduranweisungen in T n folgender Satz zeigen: Satz 3: FUr alle Prozeduranweisungen ~I
= 1
oder
~Bl = 1
s(8) gilt:
oder
ll~
- ~B~
~ I.
Dies bedeutet, daS fur die Stellung der beiden ZustandskSpfe Band nur folgende Konfigurationen
1....
I
-- -
I~
oder
auf dem
erlaubt sind:
1
I
t
1 ,-o
oder
t fi
I__ .....
{
I ''"
I~ I oder
~
1., •
I~ 1
A
oder
19
oder Ifi'k, J'k,l
Da folgl~h
keine
tigt wird,
liegt es nahe,
Information
fij in ~ Uber regul~re Definition: R =
aus dem Innern des Speicherbandes
die Erreichbarkelt
kanonische
Ein regul~res
Systeme
kanonisches
einer Prozedur
ben~-
gi oder
zu entscheiden.
System
ist ein 4-tupel
( ~ , % , S, ~) mit (i) ~
ist eine endliche,
nicht
leere Menge
( nicht termi-
hale Symbole). (ii) ~ ist eine endliche, nicht Syr~bole) mit ~ n ~ = ~ . (iil)
Sc%~ tionen
} fur
binare
(x,y) &
eines regul~ren
gung von Worten ergibt Definition:
Zu unserem
kanonischen
F~r x,y ~ %~,
~ , ~ e ~[
es existiert
Xl,X2,Yl£~ ~
Sei
Programm
Relation
~ schreiben
sich aus folgender
E konstruleren
auf
~
(Produk-
wir x--~ y)
Systems,
d.h.
die Erzeu-
Definition:
gilt x ~ ------>y u
x2~--~ Yl ~ Mit ~----> bezeichnen wir die transitive
nisches
(terminale
(Startworte).
(iv) ~ ist eine end!iche
Die Arbeitsweise
leere Menge
:
, so dab x = XlX2, y = xlY 1 und reflexive
H~lle von-----~ .
wir nun folgendes
regul~res
kano-
System
~:=
{gi }' 1 S
Die terminalen % := {0,g,f}
i S n, und
Symbole
mit g ~ ~
(fij},
1 ~ i ~ n, i ~ j ~ m i-
kanonischen
Systems
und f £ ~ . Die nicht terminalen
~[ := {(g,u,9,u),(g,u,9,u,L) (f,O,f,u)}
~=
des regul~ren
sind
Symbole
sind
, (g,u,f,O) , (f,O,g,u) , (f,O,f,O) ,(f,u,f,O) ,
mit g,~ 6 ~
;f,{£ ~
und u,O,L ~ ~ u %
drei verschie-
dene Symbole. FUr jede Anweisung wort @
(gi,u,gi,,u)
F~r jede Anweisung
gi(gi,)
des Hauptprogramms
wird genau ein Start-
konstruiert. im Rumpf yon gi werden genau zwei Produktionen
20
konstruiert.
Anweisung~
(gi~u,f,O)
(gi,u,g ,U)
~ (gi' 'u'gi"'U)
gi ' (gi" )
~ (gi''u'gi"'u'L)
gi' (fij '<Xi>)
~--g(gi''u'fij' ,O)
~ ~f (gi' 'u' fij 'O)
gi ' (Xi)
Z~
Z~
(gi''U'g'U)
fij <Xi > (gi")
"g (fij ,O,g~. ,U)
fij<Xi > (fij '<Xi>)
~g (fij 'O' fij ' ,0)
(gi' ,u,f,O)
4~~f (fij 'O'gi" ,u) "f (fij ,O, fij' ,O)
fij<Xi > (Xi)
g~g (fij ,O,g,u)
4~-f (fij ,O, f,u)
Xi (gi" )
Z-- (g,u,gi, ,,O)
~-- (f,O,gi.,u)
Xi (fie '<xi> )
Z~g (g,u, fij , ,0)
~--f(f,u,fij, ,0)
x i (xi)
@~ (g,u,g,u)
~-- (f,O, f,O)
FOr jede Anweisung im Rumpf von fij wird ebenfalls eine endliche Menge yon Produktionen konstrulert(s. Tafel I). Hierbei durchlaufen f,f ~,g ~und y ~u~.In der Matrix stehen die einzelnen Produktionen, wobei das nicht terminale Symbol der linken Seite sich am Kopf jeder Spalte befindet. Hinzu treten noch die Produktionen y (~,u,~,u,L) -- (~,u,~,u,L) @(~,u,~,u,L)
-~ @ ( ~ , u , ~ , u )
mit ~,g ~ ~.
~an kann nun zeigen: Satz 4: Eine Prozedur p in ~ ist genau dann formal erreichbar, falls es ein Startwort s, ein terminales Wort £ und ein nicht terminales Symbol (p,v,y,w) mit v,w 6 {u,Q}ly ~ ~ gibt mit s ~---> t(p,v,y,v). Da letzteres jedoch entschieden werden kann [l]j gilt der Satz 5: Es ist entscheidbar, ob eine Prozedur in einem ALGOL-60-PProgramm mit den Einschr~nkungen A und B formal erreichbar ist.
YiJ (Yij)
Yij (gi") Yij (fij"<xi>)
x i (xi)
xi (fij"<xi>)
xi (gi" )
fij'<xi> (Yij)
fij '<xi> (xi)
gi' (Yij) flj '<xi> (gi") fij '<xi> (fij"<xi >)
(~,O,gi..,u) (~,u,gi. ,u) (y,u, fij . ,O)
(fij' ,O,g,u)
(fij''O'y'u)
(g,utfi9.,O) (g,u,g,u,L)
(g,u,gi. ,u,L)
If 41-" (~,o,K,o) (~,u,~,u)
y~"
(fij' 'O'gi"'u) (fij' 'O' fij" 'O)
(gi' ,u,{,O) (gi' tu,g,u) (gi''u'g'u'L)
(gi''u'gi"'u'L) (gi' 'u'fij"'O)
gi' (gi'') gi' (fij"<xi>)
gi ' (xi)
(fij ,O,g,u)
Anwe i s u n g ~
(fij ,O,f,O)
(fij ,U, f,O)
-M-~ (f,O,gi. ,U) ~-~ (f,O,fij. ,0) ~-- (f,O,f,O)
f~-- (f,O,gi.,U) ~ (f,u,fij.,O) {~-- (f,O,f,O)
(Tafel I)
~ - ({,o,{,o) T~" (~,u,~,u)
~ . ({,o,gi.,u) g~'~ (~,u,gl.,U) y11"~y(Y,U, fij " ,O)
£n - ({,o,{,o)
f~-~f(f,u, fij . ,O)
{~- (~,o,~i,,,u)
(f,O,gi. ,U)
(~,u,~,u)
(~,u,gi..,U) (y,u,fij .,O) (f,O,f,O)
-- (f,O,fij.,U) ~M'~ (f,O,f,O)
g{ ~~f~" ff-~ ~~-~
"J~{- (~,o,g±.,u)
(fij''u'f'O)
(fij.,O,fij..,O) (fij . 'O'y'u)
(fij''O'gi"'u)
~1-" (gi' ,u,f,O)
~'~ (gi' ,u,f,O)
~'~ (fij' 'O'gi"'u) ~q'~ (fij' 'O'gi"'u) ] { ~ ~-- (fij' 'O'fij"'O) 41~- (fij.,O,flj.,O 1 {~ y~'~y(fij. ,O,y,u)IYf~Y f~'f(fij' ,O,f,u) ~'~ (fij''O'f'O) 1 ~I ~-- (flJ''O'f'u)
~-~ (gi''u'f'O)
~f~- (gi,,u,~,u)
-~" (gi' ,u,~,u)
"~ (gi' 'u'gi"'u'L) (gi' 'U'gi"'u'L) ~" (gi' 'u'gi"'u'L) 4~'~ (gi' 'u'fij"'O) ~'~ (gi' 'u'fij"'O) {~-" (gi' 'u'fij' ,O) ~ff~'~ (gi' ,U, ~',o) £'~" (gi' ,U,{,O) f-~-~ (gi' ,U,f,O) fl"
(fij ,O,f,u)
22
4o Programme mit endlichen Arten Im folgenden b e s c h M f t i g e n wir uns an Stelle von ALGOL 60-68 bzw.
60-P mit ALGOL-
ALGOL 60-68-G mit der
Einschr~nkung
C: Alle Identifikatoren von ALGOL
Algorithmen,
besitzen
endliche Arten
im Sinne
68.
die diese E i n s c h r ~ n k u n g
abpr~fen,
werden
in [3] und
[6]
behandelt. Die Annahmen scharf.
am Anfang von 2. zur B e w e i s v e r e i n f a c h u n g
Wir b r a u c h e n
sie aber nur so wenig zu lockern,
gramm von H genau eine weitere D e k l a r a t i o n wir nur e i n p a r a m e t r i g e proc
Bind hier zu
Prozeduren
dab im Hauptpro-
real d zugelassen
zulassen,
ist. Da
haben alle Arten die Form
(proc(... (proc(real))...)).
k--
J ~
n-mal / n Z O Mit der E i n s c h r ~ n k u n g und Yij(Yij)
C schiieBen wir alle A n w e i s u n g e n
aus, da sie nur bei unendlichen
und Ylj auftreten k6nnen. und Yij(xi) bewirken.
erlaubt,
Dagegen
beiden Zustandsk~pfe
die ein A u s e i n a n d e r l a u f e n
enth~it die A n w e i s u n g e n
sungen aus K 2 zur A n w e n d u n g
xi(Yij),
gelangen,
Die Konsequenz
sung der Art xi(Yij) z.B.
K1
Yij(xi) , fij,<xi>(Yij) ,
gilt Satz aus Satz
Solange nur Anwei-
3. Selbst durch Anwei3 nicht unbedin~t
kann nur dann verletzt werden, oder Yij(xi)
C die
ff in zwei Klassen ein:
K 2 enth~lt die ~brigen Anweisungen.
sungen aus K1 werden die K o n s e q u e n z e n letzt.
der beiden Zustandsk~pfe
auf dem Band bewegen kSnnen.
eines Programms
der Arten
von x i
der Arten xi(Yij)
dab wegen der E i n s c h r ~ n k u n g
sich nicht beliebig
Wir teilen die A n w e i s u n g e n
Yij(fij.,<xi>);
DeklaratorbMumen
slnd nun A n w e i s u n q e n
Es l~Bt sich jedoch zeigen,
der Arten xi(x i)
auf ~(~) mit
l~I =
ver-
wenn eine Anwei181 - I folgt
23
Weitere sinken Stets
Anweisungen jediglich
aus K1 verMndern
herunter,
aber resultiert
ist eine Folgerung aus K2 erfolgt, oberen Kopfes fortgefahren Diese
sie ihre Positionen 181 - 1 ~ Max
aus der Einschr~nkung
gilt wiederum
Satz
C. Sobald
3, wobei
nicht,
die K6pfe
tauschen
k~nnen.
(I~'l,18'I)
s 18 I- Dies
nun eine Anweisung
entweder
oder an der Stelle des mittleren
an der Stelle des
Kopfes
oder
"ganz unten"
wird.
anschauliche
Verhaltensweise
keit einer Prozedur Definition:
wobei
s'(8') mit
den Kellerinhalt
dutch
Stack-Systeme
Ein Stack-System (i) ~
legt es nahe,
Erreichbar-
zu entscheiden.
ist ein 4-tupel
ist eine endliche
die formale
S =
( ~ , @ ,S,~) mit
nicht
leere Menge
(nicht terminale
nicht
leere Menge
(terminale
Symbole), (ii) ~ ist eine endliche mit
~ n~ = ~
(iii) S c ~
(Startworte).
(iv) ~ ist eine endliche Formen
Menge von Produktionsregeln
(mit S,S' e~%
i) OAS
--->
; A,B {9;
2) QAS -->
OAS' 0S'
4) QASQ 2 --->
Ol AS'Q2
5) QIASQ2--~
OIS'AO 2
6) QIASBQ2-->
OlABS'Q 2
~Tie bei den regul~ren
kanonischen
Systemen
weise eines
Stack-Systems
mit
Definition:
Wir schreiben
wy~bwy':
eine Produktion ~
falls w,w' ~ ~ ,
wir wieder
Satz 9: Eine Prozedur
falls w 6 ~
Symbol
,Y,Y'6 %']q und in
Y,Y' 6 ~ % ~
Stack-System
~
s~ ein terminales
(p,v,y,w)
(p,v,ytw).
wir die Arbeits-
wir schreiben
~vw ~ w y w
und in ~ eine Produk-
reflexive
mit v,w
H~lle yon ~
konstruieren
p in K ist genau dann formal
in ~ ein Startwort
~iber
existiert.
die transitive
Wie in 2. l~Bt sich zu K ein genschaft
so dab s ~ > t
~
erkl~ren
~y--> Qy' existiert,
tion QIYQ2---~ olY'02 Mit ~-~> bezeichnen
der
Oi,Ql,O 2 Variablen
QABS'
3) QAS --->
minales
Symbole)
.
mit der Ei-
erreichbar,
falls es
Wort t und ein nicht
{u,O} und y £ ~ ~ u { d } g i b t ,
ter-
24
Da letzteres entschieden werden kann
Satz i0: Es ist entscheidbar,
[2] gilt
ob eine Prozedur in einem ALGOL 60-68-
Programm mit den Einschr~nkungen A und C formal erreichbar ist.
Literatur:
[1]
Bichi, J.R.: Regular canonical systems Arch. Math. Logik Grundlagenforschung
[2]
Ginsburg,
S., Greibach S.A.and Harrison, M.A.
Stack automata and compiling,
[3]
Koster, C.H.A.: Feb.
[4]
14(1961),
J. ACM 14,1
143-172
:
(Jan.
1967), 172-201
On infinite modes, ALGOL Bulletin AB 30.3.3,
1969, pp. 61-69
Langmaack,
H.: On correct procedure parameter transmission in
higher programming languages, Acta Informatica, Vol.
[s]
Langmaack, A 73/04,
H.: On procedures
as open subroutines,
2,1973
Bericht
Institut f~r Angew. Math. und Informatik der Univ.
des Saarlandes
[6]
Zosel, M.
: A formal grammar for the representation of modes
and it's application to ALGOL 68, Dissertation Washington,
[7]
Hilbert, D. Ackermann,
W.: Grundz~ge der theoretischen Logik
Springer Verlag 1972
Anschrift des Verfassers: Dipl.-Inform. Fachbereich
Wolfram Lippe
i0
Angewandte Mathematik und Informatik der Universit~t des Saarlandes 66 Saarbr~cken Im Stadtwald
1971, Univ. of
Bericht Nr. TR 71-10-O7
EINE
AXIOMATISCHE VON
STUDIE
ZUR
IDENTIFIKATION
IDENTIFIKATOREN KrUger
F.
1... E i n l e i t u n ~ Die i n P r o g r a m m i e r s p r a c h e n tifikator tion
mehrfach zu v e r e i n b a r e n ,
eines
(in
definierenden
der T e r m i n o l o g i e
Die v o r l i e g e n d e fikation.
Arbeit
gibt ist
es d a b e i ,
zu l a s s e n und m ~ g l i c h s t
intuitive
Betrachtung
einunddenselben
Iden-
das Problem der " I d e n t i f i k a -
durch
e i n angewandtes A u f t r e t e n " solchen
eine axiomatische
gew~hlte A x i o m a t i s i e r u n g
wir eine
schafft
Auftretens
von ALGOL 68) e i n e s
Unser Z i e ]
vortreten Um d i e
vorhandene M S g l i c h k e i t ,
Beschreibung
die n~tigen
allgemein
zu e r l ~ u t e r n
Identifikators. der I d e n t i -
Grundbegriffe
klar
her-
zu f a s s e n . und zu m o t i v i e r e n ,
m i t den z u g r u n d e g e l e g t e n
wollen
Abstraktionen
voranstellen. Der i n t u i t i v e
Sprachgebrauch
ten des I d e n t i f i k a t o r s real
x" - l e g t
x
bereits
ist
finierenden
ein
und einem B e r e i c h sein.
schlie~lich
schen B e r e i c h e n .
partielle Ordnung
Weiter
Deklarationen Grundbegriff
der P r a x i s
mit
einem de-
Zwischen e i n e r Relation
desselben eine
p
Stelle
erfUllt
Identifikators
Relation
y
zwi-
angemessen, d i e s e R e l a t i o n
und aus b e s c h r e i b u n g s t e c h n i s c h e n
soll s
die
Relation
eine Stelle
p
m i t der Ordnung
und s i n d
S P bl A bl X b2 => Der
nahe : M i t einem
GrUnden a l s
als
irre-
vorauszusetzen.
flexiv
also
als vierten
der D e k l a r a t i o n
dieses Auftretens,
verknUpft.
(Enthaltenseins-)
mehrerer
Es s c h e i n t
Grundbegriffe
Stelle
Bereieh
kann e i n e
Die M ~ g l i c h k e i t
verlangt
die
"das angewandte A u f t r e -
im G U l t i g k e i t s b e r e i c h
d i e Wahl d r e i e r
angewandten A u f t r e t e n Auftreten
- etwa d i e Phrase
liegt
Vorgang
der
Identifikation
bl
und
b2
X
vertr~glich
Bereiche,
so s o l l
sein ; gelten
S p b2 . sucht
zu einem
angewandten
Auftreten
ist :
26
eines den
Identifikators "kleinsten"
x
unter
den B e r e i c h e n von D e k l a r a t i o n e n
b e z U g l i c h d e r Ordnung
2~..... Die a x i o m a t i s c h e
sollen
Definition
Bereichsystem
B
und
Definition
ist
Mengen, y B
und
dab g i l t
p
2 : Es s e i e n
X
(B,S,y,p)
e i n Quadrupel
eine irreflexive
X
D c X xB
Uber
und
(xl,bl)
Ord-
s p b A byb'
=> s p b'
S xB
sind,
Ac
Xx S .
in
D
und
= (x2,b2)
Identifikationssys-
Ein ist
e i n Paar
(D,A)
Ein Ele ment ( x , b )
Yon
Auftreten
und
Identifikatoren
(B,S,y,p)
angewandtes Auftreten Yon 3 : (Gleichheit
, wobei
auf
ein Bereichsystem.
fur
(B,S,y,p) partielle
eine Relation
e i n e Menge von
definierendes
Definition
werden:
:
Vs E S V b , b ' E B :
tem
y.
nun f o r m a l i s i e r t
S
nung a u f derart
(Ao)
x
Beschreibung
Diese V o r s t e l l u n g e n 1 : Ein
von
x ,
ein
C D
Element
mit heist
(x,s) E A
x .
A)
x l
:
x2 A b l
= b2
:
x2
:
df (xl,s~)
:
(x2,s2)
xl
A
s~
s2
df Definition
4 : Es s e i
(D,A)
(B,S,y,p) = df
Lx,b
Definition
FUr
Identifikationssystem
(x,b)
{ b' ~ B :
b'
E D
heiBt
(D,A)
geeignet
~(y,s)EA~1(x,b)CD:
sei
fur
,
x =yAsp
fur
X
wenn g i l t
:
Uber
bA(b'CLx, b =>'~spb')
da~ es zu jedem angewandten A u f t r e t e n
tifikators
identifiziertes
Die I d e n t i f i k a t i o n
Uber
dann
Dieses Axiom f o r d e r t , genau e i n
X
Y b A (x,b ') ~ D},
5 : Ein I d e n t i f i k a t i o n s s y s t e m (B,S,y,p)
(At)
•
ein
definierendes
eines
Auftreten
. Iden-
gibt.
kann d a h e r b e s c h r i e b e n werden d u r c h e i n e F u n k t i o n
27
id
: A÷D
mit id(y,s) id
Das Axiom
(At)
und d i e l a e n t i f i k a t i o n s f u n k t i o n
fe der Zuordnung
L
von T e i ! m e n g e n
von I d e n t i f i k a t o r e n , (1)
.
M
B
(At)
Definfition
Daraus
und d e r
(D,A)
(B,S,y,p) = df
Mx's Die Formel
(I)
ist
lassen
.
zu d e f i n i e r e n d e n
mit
Hil-
Auftreten
~quivalent
zu
angeben, d i e
e i n e an-
a n g e w a n d t e n
~quivalente
Formulierungen
Identifikationssystem
(x,s)EA
{b & B :
Formel
des
ableiten.
ein
FUr
B
sich
Identifikation
6 : Es s e i
formuliert
spb'
von T e i l m e n g e n von
benUtzt.
sind
Formel
noch k u r z e i n e dazu ~ q u i v a l e n t e
dere Zuordnung Auftreten
von
genauer d u r c h d i e
b ' E L x , b => ~
Wir w o l l e n
sei
spb A ( x , b ) E
fur
X
Uber
dann D } .
mit
b ' E Mx, s => m b ' y b .
(2)
D i e s e Behauptung i s t b'EMx, s , folgt
b=>mspb')]
Identifikationsfunktion.
heist
Axioms
= ( x , b ) I x = y A spb A ( b ' E L x , df
so i s t
dann
gekehrt
leicht spb'
b'E Lx, b ,
(2)
d e r Annahme
und i s t spb'
folgt
einzusehen.
und mit
Gilt
(x,b')ED, (i)
also
b'E Lx, b , dann
n~mlich
(I)
und i s t
und aus d e r Annahme der W i d e r s p r u c h
so i s t
b'yb
b ' E Mx, b , m i t
und (2)
b'xb
~spb' (x,b')ED,
also
Gilt
um-
und aus
der W i d e r s p r u c h
b'yb.
3.
Zwei B e i s p i e l e
Wir w o l l e n
i n diesem A b s c h n i t t
das e i n g e f U h r t e Identifikation Als
erstes
fur
die
zwei v e r s c h i e d e n e
A x i o m e n s y s t e m angeben, in verschiedenen
Beispiel
Identifikation
w~hlen w i r
Interpretationen
die zeigen,
fur
w i e das System d i e
Sprachen b e s c h r e i b t . ein
ben~tigten
beliebiges Begriffe
ALGOL 68-Programm, range
und
to c o n t a i n
Die
28
sind
i n der S p r a c h d e f i n i t i o n
tion
ist
gegeben durch
B = Menge d e r
hinreichend
in
(x,r)
~ D
E]]9~ mit plied) rl xr2
r :
rl prz
r~ y r 2
Als
zweites
Die I n t e r p r e t a -
E~Dg~§,
S=B,
contains v
Beispiel
i n einem
riables
formalisiert.
:
rl
,
rl
:
(x,r)
: r ~Qg~§]]]
occurrence
~ A
sei
the defining
S
=
Das l i e f e r t
die
Identifikation
-Programm. folgende
(ap-
von
controlled
(x,s)
fehls, in
{~}),
va-
Ein Z~hlmechanismus o r d n e den im
Interpretation
in
~N
B = m ×(~u
der
x ,
a b l a u f e n d e n Proze~ a u s g e f U h r t e n P r o g r a m m b e f e h l e n f o r t l a u f e n d Z a h l e n zu.
r
r2 .
w~hlen w i r P ~1
bzw.
~ A
i n dem
sei x
s
( x , ) E D
s ei
fur
:
d i e Nummer des Be-
(angewandt)
ALLOCATE - B e f e h l s laufen
natUrliche
des Axiomensystems
x.
n
auftritt, d i e Nummer des
Bis
zum Durch-
des z u g e h ~ r i g e n FREE-Befehls s e i
m = ~ ,
dann werde
m = Nummer des
FREE-
Befehls gesetzt,
(nl,ml
~ y (n2,m2)
nl > n 2 A ml ~ m2 ,
s p n ~ s < m. (Dabei g e l t e
n < ~
fur
alle
Die I d e n t i f i k a t i o n s f u n k t i o n tation
gerade die
Anmerkun~ :
n E IN .) id
beschreibt
An den b e i d e n B e i s p i e l e n
sierung eigentlich
noch n i c h t
streng
Sin n e
Mengen
und
bar
statischen
interpretiert.
fikationssystem
i n der j e w e i l i g e n
Identifikationsvorschriften
B
S
e r k e n n t man, dab u n s e r e F o r m a l i -
genug i s t . werden b i e r
W o l l t e man ganz genau s e i n ,
a l s momentanen
Interpre-
i n den b e i d e n S p r a c h e n .
Ausschnitt
Die im m a t h e m a t i s c h e n dynamische v e r ~ n d e r mUBte man e i n
Identi-
im A b l a u f der P r o g r a m m e l a -
29
boration
auffassen
Folge
durch eine fehlende
und d i e
von d e r a r t i g e n
Genauigkeit
jedoch
Diskussion
der G r u n d b e g r i f f e
te Strenge
verzichtet.
4.
Reduktion
mud es s e i n , Beispiel
einer
Ausschnitten
keinen
EinfluB
hat,
haben w i r
Axiomatisierung
beschreiben.
auf die der
hier
Da d i e s e
beabsichtigte
KUrze h a l b e r
von i n t u i t i v e n
g e w i s s e i n der u n f o r m a l i s i e r t e n
auf
letz-
Vorstellungen
Theorie auftretende
beweisen .
aus den Axiomen zu
Wir w o l l e n
dies
Gesetz-
an einem
vorfUhren.
In gewissen Sprachtypen vorigen
Abschnitt
Grundbegriffe kann
im gesamten P r o g r a m m a b l a u f
yon G r u n d b e g r i f f e n
E i n e der A b s i c h t e n m~igkeiten
Identifikation
S
kann man, wie etwa an dem B e i s p i e l
zu s e h e n ,
B,S,y,p
die
auf
B
ALGOL 68
im
i n das A x i o m e n s y s t e m e i n g e b r a c h t e n und
y
reduzieren.
In
diesen
Sprachen
durch S = B
und
durch
p
spb syb v definiert
werden.
Wir werden d i e s e die M~glichkeit Vorgegeben
sei
Sprachtypen
durch d r e i
der Begriffsreduktion ein
geeignetes
Identifikationsmenge Wir
s = b
X
weitere
mit
konstruieren~
(B,S,T,p)
.
Wie ] e i c h t
das
" s2
ersichtlich,
- kurz wir
ist
klasse
von
werde s,
durch s
"-"
~
-
eine
< = > [VbEB : s l p b df
d i e Menge d e r ~ q u i v a l e n z k l a s s e n Projektion
S
(B,S,y,p)
S von
.
leistet"
Relation
- wie folgt
wie :
s2pb ] .
bezUglich
ausgedrUckt,
ein Repr~sentant
eine
"dasselbe
eine Aquivalenzrelation. in
fur
neuer Axiome e i n B e r e i c h s y s t e m
gesagt
auf
Axiome b e w e i s e n .
(D,A)
~ber einem B e r e i c h s y s t e m
Dazu d e f i n i e r e n sl
dieser
Identifikationssystem
k~nnen nun z u n ~ c h s t ohne H i n z u f ~ g u n g
(B,S,y,~)
Axiome a u s z e i c h n e n und
Hilfe
d.h.
~ .
~ , ~
Es s e i
die
sei
kanonische
die ~quivalenz-
3O
Weiter
definieren
wir
die
Relation
~
auf
~x B :
spb spb . df Diese D e f i n i t i o n i s t
unabh~ngig vom s p e z i e l l e n Repr~sentanten
Lemma i
: (B,S,¥ ~)
i s t ein ~er¢ichsystem.
BeweCs
: Wir mUssen das Axiom ~b
s
von
(AO) v e r i f i z i e r e n :
A bTb' => spb A byb ~ => spb' => spb'
Es sei nun
(D,A)
dasjenige I d e n t i f i k a t i o n s s y s t e m f u r
(B,S,y,~) ,
das gegeben i s t durch : c Xx~ (x,~) E A- [ ~ t e df
Lemma 2 : Das I d e n t i f i k a t i o n s s y s t e m
Beweis
: Wir mUssen das Axiom
dann g i b t net ist,
es
(y,t)
genau e i n
E A,
wobei
(x,b)
E D
es g i b t
genau e i n
(x,b)
S : T = T A (x,t) E A ].
(D,A)
ist
funktion,
sei
~
die
geeignet.
verifizieren.
T = ~,
Sei
und es g i b t ,
da
(y,s) (D,A)
~ A; geeig-
mit
~ D
L x , b => m t p b ~) , mit
x = y A spb A (b~E L x , b => ~ b ~ ) SchlieBlich
Uber
und
(At)
x = y A tpb A ( b ' ¢ d.h.
X
zum System
(D,A)
o
geh~rige
d.h. mit
=> m ~ b ' ) ] . i d ( y , ~ ) = ( x , b ) [ x =y A ~pb A ( b ' ~ L x,b
Identifikations-
~.
31
Lemma 3 : FUr
(y,~)
EA
Der Beweis v e r l ~ u f t
und
~hnlich
(y,s)
tionsfunktion
(B,S,x,p)
weitere
Axiome f u r
= id(y,s)
leicht
.
einsichtig.
e i n e s neuen B e r e i c h s y s t e m s erhalten,
wie d i e
~sES
~bEB : spb
(A3)
Vb~B
~sCS
(A4)
VsES
:
dessen I d e n t i f i k a -
im u r s p r U n g l i c h e n
System.
das vorgegebene B e r e i c h s y s t e m
{b : spb}
ist
wohlgeordnet
(A3)
und
Aufbau von
Wir w o l l e n z e i g e n S
: spb A ( b ' y b = > ~ s p b ' )
(A2)
: Die Axiome
"sinnvollen"
und
i-d(y,~)
ein :
die Begriffsreduktion
B
leistet"
(A2)
Anmerkung nen
Konstruktion
Identifikationssystem
"dasselbe
Wir fUhren nun d r e i
gilt
wie bei Lemma 2 und i s t
Damit haben w i r a l s o durch d i e e i n neues g e e i g n e t e s
E A
B
und
entscheidende
sind S
triviale
verlangen.
aufeinander
y .
Axiome, d i e e i (A4)
ist
die fur
Forderungo
: Unter der V o r a u s s e t z u n g d i e s e r
bijektiv
bzgl.
abbilden
und
Axiome l a s s e n s i c h
~
durch
~x B
durch
y
charakteri-
sieren. Dazu d e f i n i e r e n
wir
eine Relation
T~-b < ~ (unabh~ngig
auf
spb A ( b ' T b = > ~ s p b ' )
vom R e p r ~ s e n t a n t e n )
Lemma 4 :
~
und beweisen
a)
~ES
~IbEB
: ~b
b)
VbEB
~,sES
: T~b
c)
Ist
~b*
,
so g i l t
:
:
s~b b*Tb V b* = b . Beweis
a)
:
Existenz : Sei mit
spb .
sei
b, = b,
s
Repr~sentant von
~.
Wir k o n s t r u i e r e n eine Folge und f a l i s
es ein
b'
Nach ( A ~ ) g i b t es
bEB
F = { b , , b 2 , b s , . . . } c B.
g i b t mit
b'yb n
und
Es
spb' ~ so
32
sei
bn+ 1 = b ~.
]etztes
F
Element
ist
b*.
nicht
FUr
}eer
b*
~ b' Fo]glich
gilt
und
: Seien
spb2 ,
b,yb2
fUhrt bl
b)
wegen
(A4)
ein
und
: b ' T b A spb'
(A4)
mit
wegen
wegen
s~b,
b=yb, s~b2
s~b~
und
s~b2 .
Dann i s t
also
oder
folgt
b2yb,
b,,b2£B
nach
bIyb2 Aus
spb*
~b*.
Eindeutigkeit spb~
und b e s i t z t
gilt
oder
b,
der W i d e r s p r u c h
zum W i d e r s p r u c h
= b2 •
~spb~ ,
mspb2 .
ebenso
Daraus f o l g t
= b2.
Existenz
: folgt
Eindeutigkeit
:
Repr~sentanten b'£ B byb'
und oder
unmittelbar Seien sl
slpb'
(A3) .
sl,s~ES
und
s~
Wegen
b = b'
Umgekehrt z e i g t
aus
mit
gilt
dann
~1~b
In b e i d e n
man genauso
~1~b
gilt F~llen
und
s~pb
und
mb'yb ist
~2~b .
FUr d i e
s2pb .
und m i t
Sei
(A4)
dann aber auch
s2pb'
:
s2pb ~ => s l p b ' Insgesamt
hat man a l s o
fur
alle
slpb' Somit
c)
ist
Es g e l t e
sl
- s2
~b*,
b'E B :
s 2 p b '
und d a h e r
~I
= ~
•
also spb*
und
byb* =>mspb . Gilt
nun
s~b ,
so auch
spb~
und m i t
(Ad)
folgt
b y b * V b*yb v b* = b o Da
byb*
nach V o r a u s s e t z u n g
a u f den W i d e r s p r u c h
~spb
fUhrt,
nun
folgt
33
folgt
also b*yb v b* : b .
Die u m g e k e h r t e
R i c h t u n g der ~ q u i v a l e n z b e h a u p t u n g
Aufgrund dieses
Lemmas k~nnen w i r
mit der reflexiven
HUIIe
¥refl
nun e i n f a c h yon
¥
ist
S
trivial.
mit
B
und
gleichsetzen.
Die A b b i l d u n g f f(s) ist
:
surjektiv,
: S÷
mit
b [spb A ( b ' T b = > ~ s p b ' ) ] df
und wenn w i r
das neue System
B
(D,~)
aus dem I d e n t i f i k a t i o n s s y s t e m
mit
c (X,B) (x,b) konstruieren, Satz
:
E A [ ~ s ~ S df
so g i l t
Sei (D,A)
= b .
fur
X
schrieben Anschrift
und
kann a l s o (A4)
allein
f(s)
= b A (X,S)E A]
:
~b:r
id(x,b)
(A2) , (A3)
:
FUr d i e
fikationsfunktion
Die I d e n t i f i k a t i o n
und
schlie~lich
f(s)
(D,A)
zum I d e n t i f i k a t i o n s s y s t e m
(B,B,Y,Yrefl) id
gilt
= id(x,s) unter
geh~rige
Identi-
:
der
. Voraussetzung
durch die
Begriffe
B
der Axiome und
¥
be-
werden.
des V e r f a s s e r s
Technischen Universit~t
: Dr.Fred
KrUger,
Mathematisches
Institut
MUnchen, D-8000 MUnchen 2, A r c i s s t r a B e
21.
der
ZUR UBERSETZBARKEIT VON P R O G R A ~ I E R S P R A C H E N H. JURGENSE~
I. Einleitun~ Die erste Anregung zu den folgenden Uberlegungen zur Ubersetzbarkeit yon Programmiersprachen ergab sich aus Diskussionen im Zusammer~ang der Ausstattung des LISP-Systems f~r die ELECTROLOGICA X8 in Kiel mit einem Compiler. Das bis dahin rein interpretativ arbeitende LISPSystem war dem Rechenzentrum der Universit~t Kiel 1968 yon W. van der Poel
0 I~ zur Verf~gung gestellt und 1968-71 von F. Simon 0 6 ~ und dem
Verfasser ES] den Gegebenheiten der Kieler Anlage angepaBt und betr~chtlich erweitert worden.
1971-72 wurde der Compiler von B. Kal-
hoff C6] hergestellt und im wesentlichen im "bootstrap"-Verfahren implementiert. Bekanntlich stehen dem Bau eines Ubersetzers f~r das vollst~ndige LISP einige prinzipielle Hindernisse im Wege; Gblicherweise werden diese dadurch umgangen, da~ die Sprache fGr den Dbersetzer eingeschr~nkt wird [2,6,7,12,14,15] . Ist dieses Vorgehen auch unsch~n, so wgre es noch tragbar, wenn die Einhaltung der Einschr~nkungen zum Zeitpunkt der Ubersetzung, sp~testens aber zum Zeitpunkt der Rechnung GberprGfbar ware; fGr LISP ist dies in einigen F~llen grunds~tzlich u r ~ g lich. Wit wollen diese Aussage im folgenden pr~zisieren. Es wird sich zeigen, da~ die Schwierigkeiten allein auf Akzidenzien yon LISP zurNckzufNhren sind, die die Sprache allerdings erst programmiergerecht machen. Dadurch wird die Frage nach einem generellen Verfshren nahegelegt, mit dessen Hilfe beim Entwurf einer ~hnlich LISP universellen Programmiersprache diese Probleme vermieden werden k~nnten. Insofern sollten im weiteren die aus LISP herangezogenen Beispiele nur als Erl~uterungen der allgemeineren Situation verstanden werden. 2. Spezifische (jedoch behebbare)Probleme
eines LISP-Compilers
Von den bei der Konzeption eines Compilers fGr LISP auftretenden spezifischen Problemen lassen sieh einige unter Verzieht auf Rechengesehwindigkeit vermeiden, andere durch geringfGgige Anderungen in der "Implementationsvorschrift" des EVAL-APPLY-Zyklus [7] beseitigen
35
•
8 • Es handelt , 9sich
mit
,
1
3
•
dabei durchweg um Fragen im Zusammenhang
(I) der Bindung freier Variabler, (2) der Kommunikation zwischen interpretierten compilierten Funktionen
und
und
(3) der m~glichen unterschiedlichen "Typenvereinbarung" (CSET, DEFINE~ DEFPROP, RE~PROP usw.) zum Compilations- und Rechenzeitpunkt.
Im einzelnen vergleiche
man dazu Saunders
~4~
, S. 70 f. Die Schwie-
rigkeiten entstehen, well (I) die in LISP vorgeschriebene Variablenbehandlung eine einfache und effektive Kellerspeicherungstechnik im compilierten Programm verbietet und
(2) die Unsicherheit ~ber die aktuelle "Typenvereinbarung" aufwendige Tests zur Rechenzeit erforderlich macht.
In den bestehenden Cempilern wird meist unter Verzicht auf vollstindige Korrektheit eine LSsung vorgezogen, die sehr viel schnellere Objektprogramme
zuii~t
[6,7,10,12,15~
. Da sich die genannten Problem%
wenn auch unter Effektivit~tsverlusten, beseitigen lassen, wollen wir diese Fragen im folgenden ausklammern und insbesondere in allen Beispielen voraussetzen,
dab eine entsprechend bereinigte
LISP-Version
mit idealem Compiler benutzt wird. 3. Sich selbst ~ndernde Programme Sehr viel komplizierter
als die bisher aufgez~hlten
Probleme
der sich zur Rechenzeit
selbst ~ndernden Programme;
solche Programme
sind in LISP formulierbar, "ALGOL Y" [I~ vorgesehen.
ist das
aber auch z.B. in der Konzeption yon Wir wollen die Frage, wie welt es ~ n s c h e n s -
wert ist, sich selbst ~ndernde Programme zuzulassen, hier nicht diskutieren I). Es kom~t uns vielmehr darauf an, eine Reihe yon Forderungen herauszuarbeiten,
die man an eine Progrsmmiersprache
mit sich
selbst ~ndernden Programmen om~d an ihren Compiler mindestens sollte, um zu erreichen, compilierbar"
da~ alle "compilierbaren"
sind. Dabei lassen wir die Frage der Okonomie
pilers und der Objektprogramme Die Korrektheitsforderung wie m~glich:
f~r den Compiler formulieren wir so schwach
(Interpretation),
eine Funktion zuordnet.
des Com-
vorerst v~llig auger acht.
Es seien LI, L 2 Programmiersprachen,
ij eine Abbildung
stellen
Programme'~orrekt
Ein Compiler
die jedem Programm(text)
p6Lj
(partielle Abbildung)
c: L I --~ L 2 heine korrekt, w e ~ m (I) Quelle(c) in ~! entseheidbar I) Zu allgemeinen Komplexit~tsfragen Buchberger [4] .Zu Realisierungen
und fur j = 1,2 sei
ist
in diesem Zus~mmerahang v~l. f~r ALGOL vgl. ~17,18,19].
56
und
(2) fur alle p@Quelle(c)
gilt:
(a) Quelle(i2(c(p)))--_~
Quelie(i1(P))
~X e Quelle(i2(c(p))): und
(b) Quelle(i2(c(p)))
und
i2(e(p))(x) = il(P)(X)
ist in Quelle(i1(P))
Wir fordern also, da2 die Nicht-Compilierbarkeit
entscheidbar.
eines Programmes zu
einer Fehlermeldung f~hrt (I); wir lassen zu, da2 die durch den Objektcode definierte Funktion Einschr~nkung der durch das urspr~ngliche Programm definierten Funktion ist (2a~ und begn~gen uns damit, da2 wir diesen Unterschied eventuell erst zur Rechenzeit meldungen)
(durch Fehler-
erfahren (2b).
Die sich selbst ~ndernden Programme klassifizieren wir in solche mit expliziter Anderung (z.B. durch Deklaration) und solche mit impliziter Anderung (durch Textsubstitution).
W~hrend erstere einem Compiler
keine prinzipiellen Schwierigkeiten bereiten d~rften, m~ssen b e i d e r zweiten Klasse in der Definition der Semantik der Programmiersprache Vorkehrungen getroffen werden, um eine, worm aueh noch so un~konomische, nicht-triviale
Compilierbarkeit
zu erreichen.
3.1. Explizite Anderungen In LISP k6nnen explizite Programm~nderungen DEF~OP,
zur Rechenzeit
durch
DEFINE r CSET und ~hnliche Fumktionen durchgef~hrt werden.
Statisch entsprechen diesen beispielsweise in ALGOL 60 die Deklarationen. Explizite Programm~nderungen werden allgemein durch Anweisungen zustande k o ~ e n m~ssen, die aus (I) einer Definitions- odor Execute-Anweisung (XEQ), (2) dem Namen des zu definierenden Programmteiles und (3) dem definierenden Ausdruok bestehen. In der Terminologie yon ALGOL 60 k ~ e n grammteile
sicher Prozeduren,
als ~nderbare Pro-
eventuell aber auch Typenvereinbarungen
und Anweisungen mit ~arken in Frage. Beispiel I: DEF~ROP (BI
(L~BDA (...)
(...(DSFPROP (GSNS~) ( . . . ...))
(QUOTS SXP~))
EXPR)
sl
(...)
Ein derartiges Beispiel stellt fiat elm Compiler-orientierte s LISP-
37
System kein Problem dar; dabei ist es gleichgiiltig, ob der Compiler nach der Funktionsdefinition
innerhalb yon BI explizit aufgerufen
wird oder DEFI~OP die Compilation Gbernimmt. Definitionen global wirksam.
In LISP sind DEFPROP-
In Programmiersprachen mit statischer
Blockstruktur entsprechen der Funktion DEFPROP meist die Deklarationen; Neudefinitionen mG~ten also nur lokal wirksam sein. Das Beispiel s~he in einer solchen Sprache etwa folgenderma~en aus: begin ~ t y p e ~ procedure BI (...); begin
begin computed ~ t y p e ~ procedure
(GENSY~.~; ... ) ;
en___dd;
end;
o
end Daraus ergEben sich f~r einen Compiler keine besonderen Schwierigkeiten; selbstverst~ndlich m~Bte er zur Rechenzeit aufrufbar sein; ferner m~Bte er rekursive Aufrufe zulassen, um Deklarationen von (computed procedure, s
innerhalb des den Rmpf einer x E L(G)
3.
Zu jedem Dialog ein Wort
tA]
t]B
A! BI A 2 B 2 .... ~ tA2
t B2 .. . tk
mit A i s w (tA) , B i E w (t)
tkB
Bk
existiert
E L(G)
, i = 1,...,k •
Bei Vorgabe einer lokalen Syntax kann eine globale Syntax konstruiert werden mit Hilfe einer auf der Menge der Eingabefolgen zu definierenden'Partition mit Substitutionseigensehaft' im Sinne von Hartmanis und Stearns, siehe ~3], S. 57. Eine vorgegebene Dialogsprache ist im allgemeinen dutch verschiedene Kombinationen aus globaler und lokaler Syntax darstellbar. Je mehr syntaktische Typen die lokale Syntax vorsieht, um so mehr k~nnen die einseitig bestehenden Kontextabh~ngigkeiten zwischen verschiedenen Eingabeworten Uber die globale Syntax errant werden. Auf der anderen Seite darf aber die ~bersichtllchkeit der $1obalen Syntax nicht verlorenge-
53
hen. Man kann das aus lokaler und globaler Syntax bestehende System als eine zweischichtige Grammatik, vgl. Maurer [6] S.71, auffassen. Dabei kSnnen jedoch spezifisch interaktive Aspekte verlorengehen,
z.B. wird die semantisch bedingte Variation der
aktuellen globalen Syntax nicht erfaBt. Der Beschreibung des APL-Dialekts
HDL
liegt eine lokale Syntax mit 12 syntakti-
schen Typen zugrunde, die das folgende Aussehen hat: Benutzerseitige
lokale Syntax:
(Elemente yon
T A)
I. fur normale Eingaben im Modus direkter AusfUhrung:
regular-mode-O-statement
2. zum Einschalten des Modus indirekter AusfHhrung: mode-change-to-l-statement 3. f~r Antworten des Benutzers auf Fragen des Systems: regular answer 4. fur normale Eingaben im Modus indirekter AusfHhrung: 5. zum Einschalten des Modus direkter AusfUhrung: 6. relativ zu I. und 2. fehlerhafte Eingaben: 7. relativ zu 3. fehlerhafte Eingaben:
lokale Syntax:
mode-change-to-O-step
irregular-mode-O-statement
irregular answer
8. relativ zu 4. und 5. fehlerhafte Eingaben: Systemseitige
irregular - mode-l-statement
(Elemente yon T B)
I. fur regul~re Ausgaben und semantische Fehlermeldungen: 2. fur Syntaxfehler-Meldungen:
regular-mode-l-statement
output
~rror messase
3. fur Fragen des Systems: questio~ 4. leere Ausgaben:
em~,,ty
Globale Syntax yon
HDL :
Die Grammatik der globalen Syntax lautet G = ( {DIALOG, MODE-O, MODE-I, OPEN-MODE}~ T A ~ T B, R,DIALOG) wobei R
aus den folgenden Produktionen besteht:
I. DIALOG+MODE-O,
DIALOG
MODE-I, DIALOG
OPEN-MODE
2. MODE-O + 3. MODE-O ~ MODE-O
regular-mode-O-statement
output ,
MODE-O + MODE-O
irregular-mode-O-statement
error-message
MODE-I + MODE-O
change-mode-from-0-to-l-step
empty ,
OPEN-MODE ÷ MODE-O
regular-mode-O-statement
question
MODE-O + MODE-I
change-mode-froml-to-O-step
empty ,
MODE-I + MODE-I
regular-mode-
MODE-I+ MODE-I
irregular-mode-l-statement
MODE-O+ OPEN-MODE
regular-answer
output
OPEN-MODE+ OPEN-MODE
regular-answer
question
OPEN-MODE+ OPEN-MODE
irregular-answer
error-message
tatement
,
,
empty , error-message
,
, , .
54
Eine entsprechende Dokumentation yon Sprachen wie
APL\360, JOSS u.a. w~re mit ihn-
lichen Grammatiken mSglich. Eine weitere Anwendung besteht in der Gewinnung eines Rahmens fur spezielle syntaktische Probleme. So ergeben sich beim Entwurf yon Dialogsprachen Bedingungen an die syntaktische Strukturierung im Bereich der lokalen Syntax, die aus Forderungen nach Konsistenz, Effizienz, Kompaktheit der Notation und anderen resultieren. Das syntaktische Konzept yon
APL erweist sich als ein
Ansatzpunkt fur eine ErfUllung versehiedener solcher Forderungen. In ~5] wird hierzu yon den Autoren u.a. dargelegt, dab sich die gesamte benutzerseitige lokale Syntax von
APL-~hnlichen Sprachen im wesentlichen dutch zwei Ableitungsregeln darstellen
l~St, in denen sowohl verschiedene Datentypen als auch dialogrelevante Kontrollstrukturen auf formal gleiche Weise durch Metavariable erfaSt warden. Literatur: [I] Cameron, S.H., Ewing, D., and Liveright, M.: DIALOG: A Conversational Programming System with a Graphical Orientation, CACM, IO, No.6,pp. 349-357 (1967) [2] Falkoff, A.D., Iverson, K.E.: APL~\360 Users Manual, IBM (1968) [3] Kupka, I., Wilsing, N.: A formal framework for dialog languages, Ber. d. Inst. f. Informatik d. Univ. Hamburg, 2 (]972) ~] Kupka, I., Wilsing, N.: Syntax und Semantik de~Dialogsprachen-Konzepts HDL, Bar. d. Inst. f. Informatik d. Univ. Hamburg, 3 (1973) ~] Kupka, I., Wilsing, N.: An APL-based syntax form for dialog languages, "APL Congress 73", (Gjerl~v, P., Helms, H.J., Nielsen~ J., ads.) North-Holland, Amsterdam etc.,pp. 269-273 (]973) ~] Maurar, H.: Theoretische Grundlagen der Programmiersprachen, Theorie der Syntax, Bibl. Inst., Mannheim etc. (1969) ~] Matthews, H.F.: VENUS: A small Interactive Nonprocedural Language, "Interactive Systems for Experimental Applied Mathematics", (Klerer, M., Reinfelds, J., ads.), Academic Press, New York, London, pp. 97-1OO (1968) ~] Mc Carthy, J.: Towards a Mathematical Science of Computation, "Information Processing 1962", Proc. IFIP Congress 1962 (Popplewell, C.M., ed.) North-Holland, Amsterdam, pp. 21-28 (1963) ~] Smith, J.W.: JOSS-If: Design Philosophy, Am.Rev° in Autom. Progr., ~, 4, Pergamon Press, Oxford etc., pp. 183-256 (1970) m
Anschrift der Verfasser: Dr. Ingbert Kupka und Dipl.-Math. Norbert Wilsing, Institut fHr Informatik, Universitgt Hamburg, D-2000 Hamburg 13, SchlUterstra~e 70
D E F I N I T I O N UND I M P L E N E N T I E R U N G
EINES DIALOGSYSTEZS
H. R O H L F I N G
i. E i n l e i t u n 9
Die v o r l i e g e n d e A r b e i t d i s k u t i e r t einige E i g e n s c h a f t e n des D i a l o g s y stems KANDIS.
Das S y s t e m e n t s t a n d durch die F o r t f ~ h r u n g der in
[i]
v o r g e s t e l l t e n A r b e i t und w i r d auf der R e c h e n a n l a g e B u r r o u g h s B67OO des Informatik-Rechenzentrums
der U n i v e r s i t ~ t K a r l s r u h e implementiert.
Der Kern des D i a l o g s y s t e m s Daten- und K o n t r o l l s t r u k t u r e n
ist eine h~here P r o g r a m m i e r s p r a c h e mit
zur F o r m u l i e r u n g n u m e r i s c h e r und nicht-
n u m e r i s c h e r P r o b l e m e und mit M 6 g l i c h k e i t e n der u n m i t t e l b a r e n K o m m u n i kation
zwischen P r o g r a m m i e r e r und R e c h e n a n l a g e 0ber eine B e n u t z e r s t a -
tion. Das S y s t e m e r m ~ g l i c h t die i n t e r a k t i v e Definition, A u s f ~ h r u n g und M a n i p u l a t i o n yon Progranamen und ihre S p e i c h e r u n g als S e g m e n t e oder Moduln
in e i n e m A r b e i t s b e r e i c h .
A b s c h n i t t 2 gibt eine C h a r a k t e r i s i e r u n g der Titigkeiten, d i e s e m D i a l o g s y s t e m d u r c h f ~ h r b a r sind. A b s c h n i t t drei f u n d a m e n t a l e S y s t e m e i g e n s c h a f t e n
die mit
3, 4 und 5 d i s k u t i e r e n
zur V e r w i r k l i c h u n g dieser A u f g a -
ben, A b s c h n i t t 6 gibt einen U b e r b l i c k ~ber die D i a l o g s p r a c h e und Abschnitt 7 b e s c h [ f t i g t sich mit e i n e m I m p l e m e n t i e r u n g s m o d e l l °
2. A u r a @ b e n des Dialogs
Typische Aufgaben
des Dialogs sind:
i. die T i s c h r e c h n e r f u n k t i o n , 2. das i n t e r a k t i v e E r l e r n e n des P r o g r a m m i e r e n s , 3. die i n t e r a k t i v e E n t w i c ~ l u n g von Programmen, 4, die i n t e r a k t i v e A u s f ~ h r u n g yon Programmen, 5. der
(interaktive)
V e r k e h r mit dem B e t r i e b s s y s t e m
einer Rechenanlage.
Der B e g r i f f " T i s c h r e c h n e r f u n k t i o n ~' b e z e i c h n e t im a l l g e m e i n e n die F i h i g k e i t eines D i a l o g s y s t e m s ~
ein S p r a c h e l e m e n t - eine V e r e i n b a r u n g
oder eine A n w e i s u n g - u n m i t t e l b a r nach der E i n g a b e auszuf~hren,
babel
h a n d e l t es sich m e i s t e n s um kurze und einfach s t r u k t u r i e r t e P r o g r a m m i e r aufgaben.
56
Charakteristische Problemstellungen sind:
la. die Berechnung der Quadratwurzel einer Zahl: sqrt(7.5) lb. die Berechnung der ersten n Zweier-Potenzen: for i to n do write(i,2*~i): Ic. die L~sl~Ig
eines linearen Gleichungssystems.
In diesem Fall existiert oft ein Programm, If:n] real werte
das herangezogen wird:
:= >>n Koeffizienten des Gleichungssystems
~ADD' E
I E '-' T
=>
T 'SUB'
E/~'--T I T
=>
T = T
'*' P
T;
=>
'~' E
I P P = '(' E
')'
T
=>
P;
=>
E
IV
=>
'VAR / ' V
V = IxW
=>
'x ~
I 'Y'
=>
'Y'
I
~
~Z ~
WE I
A Transduct~ion
Grammar
Table
for Expressions
3.1
..................................................
/Y\ /
E
+
T
\
T /P
P /
/V
E
-
T
\
/T
x
x
/
P\
//P
V \
Y A Parse Tree
for x*x + (y-z) Figure
3.1a
.................................................
ADD
VAR VAR VAR VAR x An A b s t r a c t
x
y
z
Syntax Tree Figure
3. ib
for x*x + (y-z)
82
4.
The Transformation AST ~ ST
Programming languages sometimes allow more than one way to specify the same result.
For example, attributes in PL/I may or may not be fac-
tored; certain expressions may or may not be parenthesized,
etc.
Some
are more subtle, such as the assignment implied by parameter passing. The result is that there are classes of ASTs knownto the language designer to be equivalent.
The transformation AST ~ ST [4] is designed
to reduce members of the classes to single standard members, when it can be done by local renaming and reordering of tree nodes. The semantic equivalence of two constructs can be precisely stated (not the semantics, but the equivalence) the other.
by mapping one construct into
For example, in the language PALl5] we can write either E1 where x = E2
or let x = E2 in E1 where E1 and E2 are expressions.
We state the equivalence of the
constructs by the mapping in Figure 4.116]. where E1
let
~ x
xf~E2E 1 E2
A Local Tree Transformation Figure 4.1 Each transformation rule consists of two parts, an "input" template and an."output" template.
These two correspond to the left and right
parts, respectively, or a production of a type 0 grammar.
However,
in this case the intent is to reorder, expand, and/or contract a local portion of a tree, rather than a local portion of a string. To "apply" a transformation we first find a subtree that the input template matches.
This establishes a correspondence between the
"variables" in the input template and subtrees of the matched one. Then we restructure the part of the tree involved in the match, so that the output template will match it, maintaining the correspondence between variables and trees established by the i~put template match. In general, this will involve reordering, duplicating, and deleting the subtrees as dictated by the number and position of occurrences of each distinct variable in the input and output templates.
83
5.
The Transformation
The attributes writer's
ST ~ ACT
of variables
viewpoint,
are where you find them.
they are best found collected
ments clustered at the head of a variable attributes
may depend upon the context
even more subtle conditions.
More generally
in which variables
of the corresponding
tions of the program can proceed. in Table
state-
are used or
In any case they must be gathered and
tabulated before the translation the form defined
scope.
From the compiler
in declaration
Upon completion,
executable por-
the ACT may have
5.1.
program = ACT; ACT = scope; scope = symbol_table
scope* command*;
symbol table = (name attributes)*; attributes
= explicit_attributes I implicit_attributes;
Attribute-collected Table
Tree
5.1
Within a scope we first have the table of local symbols, arbitrary
sequence of nested
(scope-free) required
commands.
The transformation AST ~ ST may have been
to bring the tree into this form if a scope can be delimited
by begin-blocks
(as in Algol-60)
identified with procedure generally defined Some attributes attributes
are explicitly
are implicit.
major purposes. sary attributes
as opposed
declarations.
to being exclusively
Or the ACT can be more
to allow for the less structured
such as addresses
supplied by the programmer.
In particular,
Other
machine related attributes
An important presumption
is that there are no neces-
that cannot be derived prior to the processing code.
That is, properties
the relative location of certain instructions, effect the attributes of variables. The algorithm
use of scopes.
are to be deriv~ed by the compiler as one of its
executable machine
can be implemented,
over trees[7,8]
of the machine,
of such as
are not allowed
to
of course, as an ad hoc tree search-
ing algorithm along the lines commonly Some work has been done, however, functions
then an
scopes, and finally the executable
found in contemporary
on applying Knuth's
to this problem.
compilers.
concept of
It is a particularly
84
attractive direction since declarative information is defined to be evaluable prior to the "main"computation (i.e., execution of the program).
Knuth's functions can therefore be presumed to be evaluable
for declaration processing without any great amount of iteration, hence efficiently. The approach is to specify ST ~ ACT as a set of symbol-table-valued functions over the ST (as opposed to Knuth's functions over the PT) together with a standard ACT building process.
We suspect that a
reasonable restriction to put on declarative linguistic constructs is that they can be processed by Knuth's functions in one pass over the ST; i.e., going down the tree via function calls and then back up the tree via function returns. To apply the functions to the tree we must be able to describe the nodes.
Knuth used the names of the non-terminal symbols, numbering
only for a repeated use of a name.
When regular expressions are used
it is simpler to use a purely numeric scheme. left part of a rule; i, 2, . ~
Zero designates the
the items in the right part; -i, -2, ...
the same items numbered from right to left; (k~l), (k,2), items in each repeated term on the right, etc.
... the
For example, suppose
we have a declarative subtree of the form shown in Figure 5.1.
~~ 'B' 'BIT' i
DECLARE ~~ i
'I' 'FIXED' i
tem 'X' ~ ' ~ 3 0 0
A Declarative Subtree of a ST for DECLARE B BIT~ I FIXED~
.
.
.
X(300) FLOAT;
Figure 5.1 The objective is to compute two functions, A and S, giving the relative offset and number of bits for each item. Table 5.2 define A and S.
The grammar and functions in
Terminal nodes (name, type and dimension)
have intrinsic values provided by a primitive function val.
85
DECLARE = item +
A(I,I)
-->
= 0,
A(I,I+I)
= A(I,I) + S(I,!),
S(0) = A(I,-I) item = name type dim
_->
+ S(I,-I);
S(0) = T(2)*val(3) Cval(2) T(2)
Declarative
Functions
Table 6.
The Transformation
The implicit symbol
'FIXED'
: 16
\val(2)
'FLOAT'
: 32
over a ST
5.2
ACT ~ ADT
links by name between
the leaves of the ACT and its
tables must be replaced by explicit attachment
attributes programming
to the leaves languages
the destination
themselves.
are identical,
of the distributed
by the compiler writer. attributes
= 'BIT': 1
= ~val(2)
of the important
The scope rules of most popular from the viewpoint
of trees,
What does need to be specified
is which
are needed by the later modules.
If the distribution
is to be accomplished
leaf names with pointers
by simply replacing
into the symbol tables,
ST ~ ACT ~ ADT may as well be accomplished names are to be replaced with attributes, be kept separate.
A before-and-after
the
the transformations
as one step.
If the leaf
the transformations
need to
view of a variable node is given
in Figure 6.1.
VAR i 'I '
VAR °>
40
Attribute Distribution
'FIXED '
for a Variable
of Type FIXED and Address Offset 40. Figure 6.1 The symbol
thus
information need not be specified
table nodes are no longer needed and can be deleted.
86
7.
The Transformation ADT ~ SET
The ADT is an executable form; that is, if we had tree executing hardware.
But we do not, so we must reform the tree into equivalent se-
quential code.
We expect rather long sequences of sequential code to
be branch free.
In particular,
expressions (not including Algol-60
conditional expressions) have this property.
We can replace each sub-
tree representing an expression with its Polish form, say. go directly to single address code.
Or we can
Figure 7.1 shows an example of
such a transformation.
AS SIGN ADD f ~VAR ~ 40 'FIXED' VAR MUL
N VAR
=>
40 'FIXED
POLISH VAR VAR CONST MUL ADD
/ / VSR CONST \ 40 'FIXED ' 3
40 'FIXED' 40 'FIXED' 3
Expression Flattening Figure 7.1 Note that assignments are not included in the expression flattening, but this adds only one tier to the flattened expression trees.
The
reason assignments are left alone is two-fold: it avoids the ambiguity between variable addresses and values, and assignments need to be synchronized with some types of branching (parameters, returned values, index control for loops, etc.). 8.
The Transformation SET ~ SCT
Having flattened the trees for everything except control constructs, we must finally provide a sequential representation for branch commands.
There may be two kinds: implicit and labelled.
The implicit
branches (if-then-else, loops, case, etc.) merely require the replacement of tree links with branch links. Labels, on the other hand, must be found before the linking can be done.
While ST ~ ACT could have
collected this information, it is safely deferred to this stage.
Most
of the tree has been pruned, hence the search will not be over a very large data structure. For example, suppose we have been processing a procedure call CALL P(x+3, 4)
87
and have arrived at the SET in Figure 8.1.
x has offset 40 and the
two formal parameters (now appearing explicitly in the tree) have offsets 60 and 64. CALL ASSIGN ~AR/POLkISH
ASSIGN /~POLI SH
CONST ADD
'P '
CONST
SET for CALL P(x+3, 4) Figure 8.1 The only change needed is to replace 'P' with a pointer to the corresponding procedure definition. The tree has become a graph; all names have finally been pruned; we are ready to emit fully sequential code. i0.
Conclusion
The SCT is as far as we can go without introducing serious machine dependencies. The remaining steps in the process fall beyond the scope of this paper. We have proposed a fairly elaborate structuring of the translation process. We are trying to follow the prescription in our present translator writing system effort. We expect to simplify the task of compiler writing, but only for languages with structure amenable to the restrictions of the system. References [I] McKeeman, W. M., Compiler Structure, Proc. USA-Japan Computer Conference, (Oct. 1972) 448-455. [2] Louis, P.M. and Sterns, R. E., Syntax-directed Transduction, JACM v. 15, n. 3 (July 1968) 465-493. [3] DeRemer, F. L., Practical Translators for LR(k) Languages, PhD Thesis, MIT, Cambridge, Mass. (1969). [4] Wozencraft, J.M. and Evans, A., Notes on Programming Linguistics, Dept. E.E., MIT, Cambridge, Mass. (1971).
88
[5] Evans, A., PAL, A Language for Teaching Programming Linguistics, Proc. 23rd National Conf. of the ACM (1968) 395-403. [6] DeRemer, F.L., Transformational Grammars for Languages and Compilers TR50, Computing Laboratory, University of Newcastle-on-Tyne, England (submitted for publication). [7] Knuth, D.E., Semantics of Context-free Languages, Math Systems Theory J., v. 2, n. 2 (1968) 127-146. [8] Wilner, W. T., Declarative Semantic Definition, STAN-CS-233-71, PhD Thesis, Stanford, CA (1971).
Professor William Marshall McKeeman Information Sciences The University of California at Santa Cruz, California 95064 USA Professor Franklin L. DeRemer Information Sciences The University of California at Santa Cruz, California 95064 USA
ZUR MINIMALIT~T DES HILFSZELLENBEDARFS YON SYSTEMATISCH ~BERSETZTEN AUSDRUCKEN U. PETERS
I. K u r
z f as
sung
Wir betrachten Ausdr~cke
(im Sinn etwa von ALGOL), die aus runden Klam-
mern, un~ren und bin~ren Operatoren und Operanden bestehen,
ferner
deren systematische Ubersetzung in Folgen von DreiadreBbefehlen Kellerverfahren
(das
[I] z.B. induziert stets systematische Ubersetzungen)
und wollen den maximalen Hilfszellenbedarf yon ~bersetzten Ausdr~cken (das ist unsere Kostenfunktion)
minimieren.
Nimmt man als 0peranden
unserer Ausdr~cke einfache gew~hnlicheVariable fHr jedes Zwischenergebnis
genau 1 H i l f s z e l l e
und unterstellt man,daB ben6tigt wird, so ist
das in [2] angegebene systematische Verfahren OV optimal;
dies liegt im
wesentlichen daran, daS dann unter allen optimalen ~bersetzungen eines Ausdrucks
immer auch systematische Ubersetzungen existieren.
L~Bt man
dagegen als Operanden auch ~beriange Variable, Vektoren und derg!eichen zu und unterstellt man dementsprechend, eine positive, ben~tigt wird
zur ~bersetzungszeit
dab fur jedes Zwischenergebnis
ermittelbare Anzahl yon Hilfszellen
(diese Anzahlen bilden die sog. Best~ckung),
so ist das
Verfahren OV i.a. nicht mehr optimal, da sich nun unter allen optima!en Ubersetzungen nicht in jedem Fall systematische finden. Durch zus~tzliche Forderungen an den Ausdruck oder an die Best~ckung kann OV jedoch die Optimalit~t der Ubersetzung garantieren.
Dieses Ziel durch
eine mehr oder weniger weitgehende Verallgemeinerung der systematischen ~bersetzungen erreichen zu wollen erscheint uns dagegen aussichtslos. 2. E i n l
eitunq
Die hier betrachteten Ausdr~cke runden Klammern,
(im Sinn etwa von ALGOL)
bestehen aus
un~ren und bin~ren Operatoren und Operanden.
randen nehmen wir zun~chst gew~hnliche einfache Variable,
Als 0pe-
sp~ter dann
gew~hnliche Vektoren. Der Einfachheit halber wollen wir keine Beziehungen zwischen den Operanden zulassen: Wir setzen sie als paarweise voneinander verschieden benannt voraus.
Einen jeden solchen Ausdruck
9O
~bersetzen wir in eine Folge von DreiadreSbefehlen,
fur we!che gilt:
Wertet man den urspr~nglichen Ausdruck und die Folge von DreiadreSbefehlen
(den ~berset~ten Ausdruok)
im Sinn der Computerverkn~pfungen
so sind die erhaltenen Resultate stets identisch,
aus,
sofern die Auswertung
ohne Fehlerabbruch m~glich ist. Unter dem Hilfszellenbedarf verstehen wir diejenige Menge an Speicherzellen,
die der ~bersetzte Ausdruck zur
Abspeicherung yon Zwischenergebnissen ben~tigt. Unsere Kostenfunktion ist die Maximalanzahl von relevant besetzten Hilfszellen des ~bersetzten Ausdrucks;
diese Kostenfunktion wollen wir dutch geelgnete ~ber-
setzungsverfahren minimierent wobei wir uns jedoch auf systematische ~bersetzungen von AusdrHcken beschr~nken. verfahren von SAMELSON und BAUER
So induziert z.B. das Keller-
[i] stets systematische Ubersetzungen,
nimmt aber leider keine R~ckslcht auf unsere Kostenfunktion.
Jedem der yon uns betrachteten AusdrOcke
l~Bt sich, von unn~tigen Klam-
merungen abgesehen, bijektiv ein markierter bin~rer Bau/n zuordnen;
die-
ser splegelt die Klammerung und die Priorit~ten der Operatoren wider und es gilt: Aus jedem Knoten entspringen entweder keine oder genau zwei nichtleere ~ste.Die Zuordnung Ausdruck --- Baum schlieSt w~re sie nicht bijektiv) (Bl~tter) gen
(sonst
eine Markierung des Baums ein: Die Spitzen
des Baums sind mit den entsprechenden Operanden und die sonsti-
(inneren)
Knoten mit den entsprechenden Operatoren markiert. Da wir
fast stets gleich yon dem betreffenden
(markierten)
Baum ausgehen, wet-
den wir nut selten von Ausdr~cken und Ubersetzungsm~glichkeiten,
son-
dern vor allem yon B~umen und Abbauweisen reden° Damit unsere B~ume auch im Fall von un~ren Operatoren bin~r sind, vereinbaren wir, den dann nur vorhandenen einen Operanden als Linksoperanden des un~ren Operators zu behandeln und als Rechtsoperanden elnen operanden PSO dazuzunehmen.
Beispiel
zeichen) : Aus ~(a/(~(b-c)))
wird
k~nstlichen Pseudo-
("~" bezeichne das un~re Minus-
(a/((b-c)%PSO))%p~so.
zur Bijektivit~t
der Zuordnunq Ausdruck 4-- Baum sei schlieSlich noch angemerkt, dab wir voraussetzen,
dab f~r den Fall der Zusammenfassung mehrerer Operatoren
der gleichen Priorit~t eine Eindeutigkeit erzeugende Konvention vorhanden ist. In unseren Beispielen schlieSen wir uns dabei an ALGOL 60 an; so ist etwa mit dem Ausdruck a+b+c+d der Ausdruck
((a+b)+c)+d gemeint.
91
3. P r
~ l i m i n a r i e n
Definition
i:
Ein bindrer Baum B ist eine endliche,
n i c h t l e e r e Menge yon Z e i c h e n r e i -
hen K, Knoten genannt,
aus
von K E B zu B geh6rt.
Wir v e r l a n g e n zusMtzlich, dab m i t K, KO c B
{0,I} W , so dab jede A n f a n g s z e i c h e n r e i h e K'
auch K1 ~ B und mit K, K 1 E
Anmerkung: erw~hnt,
B auch KO ¢ B ist.
Die von uns b e t r a c h t e t e n B~ume sind, w i e in der E i n l e i t u n g
z u s M t z l i c h marklert.
Bedeutung,
Die M a r k i e r u n g ist jedoch so se!ten von
da8 wir sie nur dann a u s d r ~ c k l i c h im Text e r w ~ h n e n bzw.
den B e i s p i e l e n h i n s c h r e i b e n ,
falls sie gerade w i c h t i g
Die totale O r d n u n g 0 < 1 der Menge
in
ist.
{0,I} i n d u z i e r t eine l e x i k o g r a p h i s c h e
O r d n u n g < • der K n o t e n eines Baums. FUr
" K' ist echte A n f a n g s z e i c h e n -
reihe von K " s c h r e i b e n wit K' < • K.
D e f i n i t i o n 2: K' ist Naohfolger von K, w e n n E' = KO o d e r K' = K1 ist. U m g e k e h r t d a n n K Vorg~nger von K'; ferner sind KO und K 1 N a c h b a r n
ist
voneinander.
Knoten, die b e z ~ g l i c h < • m a x i m a l sind, nennen wir Spitzen
(BlHtter),
die O b r i g e n K n o t e n n e n n e n wir innere Knoten, den b e z ~ g l i c h < • m i n i m a len
(leeren)
Bezeichnung:
K n o t e n e nennen wlr Wurzel des Baums B.
Mit dem E p s i l o n ~ b e z e i c h n e n wir sowohl die W u r z e l n u n s e r e r
B~ume als auch die m e n g e n t h e o r e t i s c h e E l e m e n t b e z i e h u n g ;
aus dem K o n t e x t
geht immer e i n d e u t i g hervor, was jeweils g e m e i n t ist.
D e f i n i t i o n 3: Eine Abbauweise M i s t (IK,< .) auf und
[l:x]
bijektive,
eine bijektive,
([l:IIKl],>), wobei
:= {i ¢ NI
1S
o r d n u n g s t r e u e A b b i l d u n g von
IK die M e n g e der inneren K n o t e n yon B
i ~ x} ist. Die Kellerabbauweise
M K ist die
in b e i d e n R i c h t u n g e n o r d n u n g s t r e u e A b b i l d u n g yon
(B,< .) auf
([1:IIKI],>).
A n s c h a u l i c h g e s p r o c h e n ist eine A b b a u w e i s e eine A u f z ~ h l u n g der inneren K n o t e n eines Baums, w o b e i l e t z t e r e m i t der O r d n u n g < • des Baums "vertr~glich"
sein muB. G e d a n k l i c h geh~rt zu einer A b b a u w e i s e
G e n e r i e r u n g der z u g e h ~ r i g e n D r e i a d r e B b e f e h l s f o l g e dazu.
auch noch die
92
Anmerkung:
U n t e r einem Ubersetzungsverfahren
stehen wir einen A l g o r i t h m u s ,
bzw. Abbauverfahren
ver-
der, a n g e w a n d t auf einen A u s d r u c k bzw.
m a r k i e r t e n Baum, eine U b e r s e t z u n g dieses A u s d r u c k s g e n e r i e r t bzw. einen A b b a u des m a r k i e r t e n Baums d u r c h f H h r t und damit ebenfa!is einen ~bersetzten A u s d r u c k generiert.
Anmerkung:
Die K e l l e r a b b a u w e i s e ist gerade die vom K e l l e r v e r f a h r e n
d u z i e r t e Abbauweise.
Dabei stellen wir B~ume a n s c h a u l i c h so dar, dab
die l-Zweige nach links und die O - Z w e i g e nach rechts gehen, B =
in-
{e,O,l,O0,Ol,lO,ll,lO0,101}
z.B.
f~r
:
D e f i n i t i o n 4: • ~ K }von
B n e n n e n wir Teilbaum yon B
Eine A b b a u w e i s e M heiBt systematisch,wenn
f~r jeden inneren Knoten K,
Die T e i l m e n g e T K := { K'
I K'
mit der Wurzel K. D e f i n i t i o n 5:
fur den auch K1 und KO innere Knoten sind, e n t w e d e r max
{M(K')}
~ IK(TKI)
{M(K') }
max
gilt. A n s c h a u l i c h g e s p r o c h e n ist eine A b b a u w e i s e den T e i l b a u m T K
(K innerer Knoten)
systematisch, wenn fur je-
e n t w e d e r zuerst alle inneren Knoten
des linken Astes TKI von T K und dann alle inneren K n o t e n des rechten A s t e s TKO a u f g e z ~ h l t w e r d e n oder umgekehrt;
a b s c h l i e S e n d ist K selbst
93
aufzuz~hlen;
auf Grund der D e f i n i t i o n
3 einzelnen A u f z ~ h l u n g e n gez~hlt w e r d e n d~rfen. Satz
keine
gilt weiter,
sonstigen
Beispie!e
dab zwischen diesen
inneren Knoten des Baums auf-
f~r systematische
Abbauweisen
liefert
I:
Kellerabbauweisen
sind systematisch.
Beweis: Seien K,KI und KO innere Knoten von B. FHr alle Klx, KOy ~ B gilt: Klx .> KOy. Nach D e f i n i t i o n
foigt: MK(KIx)
max{MK(Klx) } < min{MK(KOy) }
q.e.d.
4. D e r
g ew@hn
1 i che
In diesem A b s c h n i t t fache g e w @ h n l i c h e
duziert,
und unterstellen,
ben~tigt wird.
unserer A u s d r ~ c k e
Wir geben ein A b b a u v e r f a h r e n
dab OV f~r jeden Baum eine systematische A b b a u w e i s e
die bez~glich
k(K)
ein-
daS f~r jedes Zwischener-
unserer K o s t e n f u n k t i o n
optimal
nieren wir zun~chst die sog. B a u m b e w e r t u n g s f u n k t i o n :=~O
(FI)
Damit:
1
nehmen wir als O p e r a n d e n
Variable
gebnis nur 1 Hilfszelle an und zeigen,
F al
< MK(KOy).
OV in-
ist. Dazu defi-
k I B ~ INo:
, falls K Spitze Yon B
[ min{maxKl,maxKo}
, sonst
mit maxKl
:= max{k(Kl) ,l+k(KO) }
maxKo
:= max{k(KO) ,l+k(Kl) } .
(F2)
Definition
des V e r f a h r e n s
OV:
Sei A der zu ~ b e r s e t z e n d e Ausdruck. i) Man erstelle den zu A gehSrigen m a r k i e r t e n
Baum B und bewerte
B ge-
m,S der Funktion k aus (FI), indem man jeden Knoten K ~ B mit k(K) ~ markiert. 2) Man baue B system sch ab unter B e r ~ c k s i c h t i g u n g der folgenden Vorschrift: tun;
Ist K Spitze yon B, so ist fur den A b b a u yon T K nichts
zu
ist K innerer Knoten von B, so treffe man gem~B dem A s t a u s w a h l -
Kriterium
(F3) die Entscheidung,
ob zuerst TKI und dann TKO abzu-
94
bauen ist oder umgekehrt.
Astauswahl-Krlterium:
(F3)
maxKl S maxKo ~
TKI zuerst abbauen
Def
(andernfalls TKO)
Satz 2: Sei A der zu Gbersetzende Ausdruck und B = T g der dazugeh6rige markierte Baum. Dann gilt: k(z) gibt den maximalen Hilfszeilenbedarf des gem~B OV Gbersetzten Ausdrucks A an. Beweis: Siehe [5] , Satz I0. FUr die Praxis handlicher werden die Funktion k und das Astauswahlkriterium dutch folgende Umformung: I (FI')
k(K) =
0 k(Kl) l+k(Kl) k(KO)
(F3')
k(Kl) ~ k(KO) ~
falls K Spitze von B falls k(Kl) > k(KO) falls k(Kl) -- k(KO) falls k(Kl) < k(KO) TKI zuerst abbauen
(andernfalls TKO).
In dieser Form findet sich OV in [2], [3] und [4].
Bezeichnungen: Sei A ein Ausdruck und M ein Abbauverfahren°
Dann sei MAdie von M in-
duzierte Abbauweise von A, MA(A) der gem,S M A ~bersetzte Ausdruck und MH(MA(A))
der Maximalbedarf
an Hilfszellen von MA(A). Dann gilt, wenn
E die Wurzel des zu A geh~rigen Baums ist, nach Satz 2: MH(OVA(A)) Damlt kann man zelgen Satz 3: Das Verfahren OV ist optimal, d.h. es gilt: (VA) (VMA) (MH(OV A(A)) S MH(M A(A))). Beweis: Siehe
[5] , Satz ii.
=k(~l
95
Satz 4: Im g e w G h n l i c h e n Fall gibt es u n t e r allen o p t i m a l e n A b b a u w e i s e n stets auch systematische.
Beweis: Dies folgt u n m i t t e l b a r aus der D e f i n i t i o n von OV und Satz 3.
5. D e r
vet
al
i g e m e i n e r
te
Fall
In d i e s e m A b s c h n i t t n e h m e n wir als O p e r a n d e n u n s e r e r A u s d r G c k e w i e d e r g e w ~ h n l i c h e Gr~Ben,
aber d i e s m a l nicht nur e i n f a c h e Variable,
auch G b e r l a n g e Variable,
Vektoren, M a t r i z e n und dergleichen.
sondern Dement-
s p r e c h e n d u n t e r s t e l l e n wir nun, dab fGr jedes Z w i s c h e n e r g e b n i s ~bersetzungszeit
ermittelbare,
eine zur
p o s i t i v e A n z a h l von H i l f z e l l e n b e n S t i g t
wird. Diese A n z a h l e n g e b e n wir uns in F o r m der sog. B e s t G c k u n g s f u n k t i o n h
J IK ~IN vor, w o b e i IK w i e d e r die M e n g e der inneren Knoten von B ist
und h(K)
den H i l f s z e l l e n b e d a r f des zum inneren Knoten K g e h S r i g e n Zwi-
schenergebnisses
angibt. Wit w e r d e n nun die B a u m b e w e r t u n g s f u n k t i o n k
und damit das V e r f a h r e n OV v e r a l l g e m e i n e r n und p r G f e n
, in w e l c h e m Aus-
maB OV w e i t e r h i n o p t i m a l ist.
V e r a l l g e m e i n e r u n g der F u n k t i o n k: 0
(F4)
k(K)
:=
, falls K Spitze von B
max{h(K), min{maxKl,maxKo}}
, sonst
mit maxKl
:= max{k(Kl) ,h{Kl)+k(KO) }
maxKo
:= m a x { k (KO) ,h (KO) +k (KI) }.
(F5)
Dabei w i r d v o r a u s g e s e t z t , h(K)
dab h auf ganz B f o r t g e s e t z t w u r d e v e r m 6 g e
:= 1 fGr alle Spitzen K yon B.
Die D e f i n i t i o n des V e r f a h r e ~ O V
mit seinem A s t a u s w a h l - K r i t e r i u m
(F3)
gilt unver~ndert. Satz 5: Sei A der zu G b e r s e t z e n d e A u s d r u c k und
(B,h)
=
(T ,h) der d a z u g e h ~ r i g e
96
best~ckte
(und markierte)
Baum. Dann gilt: k(¢) gibt den maximalen
Hilfszellenbedarf des gem~B OV ~bersetzten Ausdrucks A an. Beweis: Siehe [5] , Satz 18. Wieder l~Bt sich die Funktion k und das Astauswahl-Kriterium
(F3)
urn-
formen : O (F4 ')
k (K) = {
falls K Spitze von B
max{h(K) ,k(Kl)} f~r k(Kl)-k(KO)
> h(Kl)
max{h(K) ,k(KO) } f~r k(Kl)-k(KO)
< -h(KO)
max{h(K) ,h(Kl)+h(KO)+min{d(KO) ,d(Kl) }} , sonst wobei d(K)
:= k(K)-h(K) gesetzt wurde.
Man ~berzeugt sich leicht, dab sich daraus f~r h ~ 1 die Funktion k aus (FI') ergibt. Das Astauswahl-Kriterium
(F3) l~Bt sich wie folgt umfor-
men: (F6')
d(Kl) ~ d(KO) ~
TKI zuerst abbauen
(andernfalls TKO)-
Man ~berzeugt sich leicht, dab sich daraus f~r h ~ i das AstauswahlKriterium
(F3') ergibt.
(F6') wird in [5] als Formel
(F34) abgeleitet.
Bezeichnungen: Wir ~bernehmen die Bezeichnungen A, M, M A, MA(A) und MH(MA(A))
aus Ab-
schnitt 4. Ferner bezeichne MAS eine systematische Abbauweise M A v o n
A
und (B,h) den zu A geh~rigen best~ckten und markierten Baum. Nach Satz 5 gilt: MH(OVA(A))
= k(¢). Damit ist formulierbar
Satz 6: Das Verfahren OV ist relativ optimal, d.h. bez~glich aller systematischen Abbauweisen MAS von (B,h) gilt: (VA) (VMAs) (MH(OVA(A)) ~ MH(MAs(A))). Beweis: Siehe
[5] , Satz 20.
Leider ist OV nun aber nicht mehr absoiut, d.h. fur jeden best~ckten Baum (B,h), optimal, wie etwa der folgende Satz ergibt:
97
Satz 7: Zu jeder B a u m l ~ n g e m ~ 4 gibt es einen b e s t H c k t e n Baum
(B,h) , f~r w e l -
chen OV nicht optimal arbeitet.
Beweis:
Siehe
[5], Satz 24.
Wit b e s c h r ~ n k e n uns h i e r darauf, ein k o n k r e t e s B e i s p i e l anzugeben, w e l c h e s O V nicht optimal arbeitet. (B,h)
f~r
Sei
= { (~,4) , (1,25) , (0,20) , (11,3) , (10,2) , (01,12) , (00,ii) , (111,26) (110,5) , (I01,I) , (i00,I) , (011,i) , (010,i) , (O01,i) , (O00,I) , (Iiii,I) , ( i i i 0 , i )
Wie erinnerlich,
, (ii01,I)
, (iiO0,I)
h a b e n wit die B e s t ~ c k u n g h v e r m ~ g e h(Spitze)
ganz B fortgesetzt.
:= 1 auf
In u n s e r e m B e i s p i e l slnd die Spitzen die e i n z i g e n
Knoten mit der B e s t H c k u n g
i. Um V e r w i r r u n g e n zu vermeiden,
stellt, daS der t a t s ~ c h l i c ~ Z e l l e n b e d a r f der Ausdrucks
}.
so klarge-
( O r i g i n a l - ) O p e r a n d e n des
f~r alle B e t r a c h t u n g e n d i e s e r A r b e i t u n e r h e b l i c h ist, da wit
voraussetzen,
dab die O r i g i n a l o p e r a n d e n u n m i t t e l b a r in den e r z e u g t e n
D r e i a d r e S b e f e h l e n v e r k n ~ p f t w e r d e n k6nnen. Das angegebene B e i s p i e l b e s i t z t 896 m ~ g l i c h e A b b a u w e i s e n , w o v o n 16 system a t i s c h und 112 o p t i m a l sind; der m i n i m a l e M a x i m a l b e d a r f b e l ~ u f t sich auf 45 Hilfszellen.
Die folgende o p t i m a l e A b b a u w e i s e sei h e r a u s g e g r i f f e n :
Knoten
aktueller Hilfszellenbedarf
Ii0
5
Iii
31
ii
3
O0
14
Ol
26
O
23
I0
25
1
45 4
Mit
(F4) und
(F5) folgt welter:
keine s y s t e m a t i s c h e A b b a u w e i s e , auskommt.
k(~)
= 48; nach Satz 6 gibt es also
die mit dem M i n i m u m von 45 H i l f s z e l l e n
Mit d i e s e m B e i s p i e l und Satz 6 folgt
Satz 8: Es gibt b e s t H c k t e B~ume
(B,h), d e r e n s ~ m t l i c h e o p t i m a l e A b b a u w e i s e n un-
98
systematisch
sind.
In genau diesen F~llen arbeitet das V e r f a h r e n OV
nicht optimal.
Wegen der Bekanntheit
und E i n f a c h h e i t
aber doch darum bemGht, terhin optimal
des V e r f a h r e ~ OV haben wir uns
F~lle h e r a u s z u k r i s t a l l i s i e r e n ,
in denen OV wei-
ist:
Satz 9: Das V e r f a h r e n OV ist fur den Ausdruck A optimal, (VMA) (MH(OV A(A)) falls L~nge
d.h. es gilt
S M H ( M A(A))) ,
(B) ~ 3 oder falls fur jeden inneren Knoten K von B min-
destens eine der folgenden Bedingungen
gilt:
I) K1 oder KO ist Spitze von B 2) k(Kl)
- k(KO)
>_ h(Kl)
3) k(Kl)
-k(KO)
2,..., % - 1 best~ckten Baum
> I, so gibt es einen ~ 2 und b m _
(B,h) so, dab die T e i l - A b b a u w e i s e n M1 und MO von T 1 bzw.
T O ailer o p t i m a l e n A b b a u w e i s e n M des Baums B auf die v o r g e g e b e n e Art verzahnt sind, d.h. diese V e r z a h n u n g e n sind erzwingbar. A l l e s o n s t i g e n Verza~ngen
mit b i ~ 1 fHr i = l(1)n sind nicht erzwingbar.
nahme: F~r B = { ¢ , 0 , i , 0 0 , 0 1 , I 0 , i i } Beweis:
Siehe
gilt b I = b 2 = I.
[5], Satz 25.
Es sind also n a h e z u alle V e r z a h n u n g e n erzwingbar. Meinung,
D e s h a l b sind wir der
dab man nur mit g r u n d s ~ t z l i c h neuen Ideen ein V e r f a h r e n finden
kann, w e l c h e s zu jedem b e s t ~ c k t e n und m a r k i e r t e n Baum 1 optimale Abbauweise
6. L i t i]
era
Samelson,
Nakata,
liefert.
K.', Bauer, F.L.:
I.: "On C o m p i l i n g A l g o r i t h m s
Redziejowski,R.R.: A C M 12, 81 - 84
[4]
for A r i t h m e t i c E x p r e s s i o n s " ,
"On A r i t h m e t i c E x p r e s s i o n s and Trees", Comm. (1969)
Sethi,R., U l l m a n n , J . D . :
Peters, U.:
"The G e n e r a t i o n of O p t i m a l Code for Jo~r. A C M i_~7, 715 - 728
(1970)
"Der H i l f s z e l l e n b e d a r f yon ~ b e r s e t z t e n A u s d r H c k e n " ,
Dissertation,
Institut fur A n g e w a n d t e M a t h e m a t i k und I n f o r m a t i k
der U n i v e r s i t ~ t des Saarlandes, D-66 S a a r b r ~ c k e n II
A n s c h r i f t des Verfassers: Dipl.-Math.
Comm.
(1967)
Arithmetic Expressions", [5]
"Sequential F o r m u l a T r a n s l a t i o n " ,
(1960)
Comm. A C M i_O0, 492 - 494 [3]
(B,h) m i n d e s t e n s
t u r
A C M ~, 76 - 83 [2]
Einzige Aus-
Ulrich Peters
Institut fur A n g e w a n d t e M a t h e m a t i k und Informatik der U n i v e r s i t ~ t des Saarlandes D-6600 S a a r b r ~ c k e n
ii / St. J o h a n n e r S t a d t w a l d
(1973)
A PASCAL COMPILER BOOTSTRAPPED ON A DEC-SYSTEM 10 G. FRIESLAND ~ C~O.__GROSSE-LINDEMANN~
P~W. LORENZ~
H.-H. NAGEL, P.J. STIRL
Abstract A new PASCAL (1) compiler, developed at the ETH ZGrich
(2), has been
successfully bootstrapped on to a PDP-10 within 7 months by the equivalent work of 3 students.
The approach differed from (3) insofar as no
other computer has been used during this process. conclusions
concerning the bootstrap procedure,
Our experience and
the compiler from which
we started and the language PASCAL are reported.
I Based on the experience of teaching an introductory science,
at Hamburg University
limited control and data structuring facilities guages
course in computer
since summer 1972, it was felt that the of the available
(essentially ALGOL 60 and FORTRAN IV) were insufficient
many nonnumerical programming problems.
lan-
for
The independent implementation
of a mor@ powerful language for the DEC-System 10/50 at the Institut fQr Informatik was way beyond our resources. PASCAL-Compiler written in PASCAL appear feasible
The availability of a
(1,4,5), however, made a bootstrap
- an impression reinforced by the example for the Bel-
fast ICL 1900 (3). Compared to the Belfast approach the situation at Hamburg differed in that such a project would have to be carried through by students who had no previous experience with compilers,
the
language PASCAL or the DEC-System 10 which became operational here in November 72. In addition, no trip to Z~rich could be financed nor was any other CDC-installation with a running PASCAL-compiler accessible to us at that time. We therefore
investigated a bootstrap using our PDP-IO only, based on
a PASCAL source version and a corresponding CDC 6000 object version of the PASCAL compiler
(4,5) which we obtained together with the CDC as-
sembly language runtime s u p p o ~ from the ETH ZUrich.
During the winter
term 72/73 a simulator for the CDC 6000 series was deve~ped in MACRO-10~ the DEC-System
10 assembly language.
Simulating the execution of the
102
CDC object code version of the PASCAL compiler required a special bare bones
(23 k word) monitor version, only usable during night shifts and
weekends:
our installation is equipped with only 65 k words, 56 k of
which were.required by code and working space for the CDC object version of the PASCAL compiler
(2 PDP-IO words ~ 36 bit for each 60 bit
CDC word), about 2 k words for the simulator of the CDC 6000 processor as well as the runtime support of the compiler and the remaining 4 k words were required for I/O buffers, debugging support and working space. In March 73 we succeeded in compiling the PASCAL source version of the compiler,
taking more than 90 minutes real time on a dedicated
PDP-IO - to be compared against 55 seconds to execute the same compilation on the CDC 6400 at the ETH Z~rich
(5). Since we had not yet im-
plemented the simulation of floating point instructions,
the object
code of the compiler obtained by simulation at Hamburg was not completely identical to that obtained from ZHrich. These experiences
(6) indi-
cated that a bootstrap without recourse to a faster executable
compiler
version would become rather laborious.
II Therefore we decided to bootstrap the new PASCAL compiler veloped during this period. new compiler generates
(2) being de-
In order to improve its portability
code for an hypothetical
stack computer
(7) the (SC)
rather than for the CDC 6000 series. The SC was communicated to us (8) in form of a short description and the listing of a PASCAL program to interpret SC-code.
On this basis an interpreter was written in MACRO-IO
and debugged by two students in about two weeks.
After having obtained
(April 8, !973) a magnetic tape with a PASCAL source file and a SC object code file of the new PASCAL compiler, two innocent details caused considerable work until we were able to compile the PASCAL source version by using our SC-interpreter to execute the SC object code version of the compiler. The SC relies on storing data with type-attributes real, boolean,
set, pointer,
(undefined, integer,
stack mark). These are also helpful for
runtime checks, reading stack dumps etc. The original MACRO-IO version of the SC interpreter used one PDP-IO word for the type attribute and the next one for the actual data value. This representation,
however,
required so much space for the runtime stack during compilation of the compiler that more core was required than available.
Consequently the
type attribute was packed as a 3 bit field together with data into one PDP-IO word - making it impossible to use the full word for storing,
103
e.g., a complete PDP-IO instruction. using only 59 of the 64 character representations
Moreover,
in the CDC
display code, the SC at ETH ZHrich could store entities of type SET OF CHARacters
in one 60 bit CDC-word.
This is not possible on the PDP-IO
with a word size of only 36 bits. Loading,
storing or passing variables
of type SET OF CHAR requires a two word transfer whereas the original SC version only had provisions
for one word variables.
Three principal
modifications were necessary
1. In the PASCAL source version of the compiler entities of type SET OF CHAR must be endowed with a size of 2 (words) rather than 1 (word). 2. The SC object code has to treat such objects as 2 word entities. 3. The SC object code has to generate the appropriate
code for handling
such entities.
Using the well known T-notation
(9) the steps leading to reproducibili-
ty of the PASCAL compiler generating code for the SC on our DEC-System 10 can be depicted as obtained from ZUrich
I,
c
generated at Hamburg
ZC
IpA'cAL .... > .~r ZC .. , ,,.,j ~ .o,i,ico_,io. ,) 1PA.ECAL.
,~T.., v,.,, I
IPA,.*CCAL 1
IPA CAL
.sET...~ ...o,..,]
,sc' l....
=>
:=>
tPAZCAL
,,~,,,,°,i,,c,,~,o,,,
~c]
>zEr...~,.o...,~
104
PA
ECA L
>
'.
,EC
/ / / /
IPAECAL~PAECAL
+;d;I
/CJ
Sz~,,,,.Z b,,,.,c,[ I,~E'r',,,.2 o,.,~s]
L+~'+.I .~ w,,+,.~+
M~ CRo-i~
It
took
SC o b j e c t (hatched
about
two m o n t h s t o
code before T),
a long time
sembly language. fact
that
the
it
necessary
the
SC o b j e c t
SO v e r s i o n
modifications
to reproduce
compared to writing
Modifying
entire
debug the
was p o s s i b l e
of the
the
this
object
SC i n t e r p r e t e r
c o d e was a g g r a v a t e d compiler
appears
in the code in asby t h e
as one a b s o l u t e -
ly addressed piece of code. The representation of the SC code for the compiler in the PDP-IO requires 13.0 k words + 1.5 k words for constants,
the runtime stack for
the compilation of the PASCAL compiler generating code for the SC requires 13.5 k words and the PDP-iO object version of the SC interpreter together with the necessary runtime support 2.5 k words. The execution of such a compilation requires 7-8 minutes real time on a dedicated PDP-IO:
a significant advance from the CDC 6000 simulator.
The preceeding discussion shows up to what extend portability might be hampered by implicit machine dependence.
There is another example for
this encountered during our bootstrapping process, namely the dependence on character code representation.
The PASCAL as well as the SC
version of the compiler obtained from ETH Z~rich use the 6-bit-CDC-display code whereas the DEC-System iO relies on 7-bit-ASCll ternal representation of characters.
code for in-
Immediate transfer to the 7-bit-
ASCII code would have required three groups of modifications: 1. Conventions in the ASCII representation
should be used for those
PASCAL symbols that are not contained in the subset of 7-bit-ASCII characters
available at our installation.
This problem is not quite
trivial since no single EOL ("end of line") character is available in our subset of 7-bit-ASCII,
the "end of line" being represented by
105
the sequence:
carriage return - line feed.
2. Adapting the PASCAL source version of the compiler to the new conventions.
There are several instances
in the new PASCAL compiler
where it relies explicitly on the order of the 6-bit-CDC-display code to select subranges for declaring and accessing arrays with index expressions of type CHARacter.
These instances
avoided by appropriately using the available PASCAL. however,
Most of these modifications small generalisations
can all be
language features of
are trivial editing operations;
in the logical treatment of entities
with type SET OF CHAR are required
(no modifications
are required
for the CASE statement with tagfield type CHAR). 3. The consequences
of the above adaptations have to be incorporated
into the SC object code version of the compiler. It was decided against converting the PASCAL and SC version of the compiler to 7-bit-ASCll but to wait until some agreement would have been reached with respect to handling end-of-l~ne situations
and a compiler
object version generating code for the DEC-System 10 could be reproduced correctly on our installation. in the meantime mented.
Both conditions have been fulfilled
(IO) and the conversion to ASCII is just being imple-
In the meantime we converted the ASCII input file to the SC
interpreter into CDC-display code and reconverted the output file from display code back to ASCII code.
III Parallel to these activities duce code generation
two students investigated how to intro-
for the DEC-System
10 into the compiler.
The com-
pilation process for a simple example was evaluated and only those code generation procedures were inserted that were necessary to obtain the expected PDP-10 code for this example.
Based on this experience
ing all important parts of the compiler - the main problems
- touch-
could be
identified and a time schedule for their treatment be planned.
Since
both students should not spend much more than half a year on this task and nevertheless
obtain a compiler directly executable
on our DEC-
System 10, some of the following decisions have been influenced by this condition: 1. The new compiler
(2) generates code as soon as possible, using the
runtime stack to hold results of evaluated subexpressions. respect it is similar to the first PASCAL compiler the CDC 6000 X-registers
In this
(5) which used
as a register stack. As already noted for
106
the old compiler
(3,11) this approach requires either complete re-
writing of the expression evaluating parts or accepting severe inefficiencies
in the code generated for machines that may combine
registers directly with operands in memory. vides 16 accumulators
Since the PDP-IO pro-
of which 15 may be used as index registers as
well, we could use a large fraction of these to implement a register stack - an option not open for the ICL 1900 series
(3). We decided
to do this and postpone an optimization that can only be obtained by considerable redesign of those parts analysing expressions. 2. The availability of many index registers would allow a realization of the display register concept - suggested, first PASCAL compiler
e.g., by Wirth for the
(5); it can be found, too, in the architecture
of the Burroughs B 6700 computers
(12)o Hoare observed - quoted by
Wirth in (13) - that most of the variables used in a procedure either declared locally or globally.
It seems to be more economical
to dynamically evaluate the proper environment ed at an intermediate
are
for a variable declar-
level whenever it is used rather than update
the display registers every time a procedure is left. We adopted this solution and - as a consequence
- changed the declaration of
some ra~her frequently used variables
from their original interme-
diate level to the global level. 3. Although the PDP-IO version of the PASCAL compiler should eventually generate absolute, directly executable
code, it seemed advantageous
to output the generated code during the conversion phase in the form of MACRO-IO assembly language.
The extra assembly step enabled us to
generate absolutely addressed code in the compiler and nevertheless link on the runtime support in assembly language and the DEC-System 10 dynamic debugging package in a loader run on the relocatable ject code generated by the assembler.
ob-
Since the PASCAL compiler as
received from ZUrich only had provisions
for one standard input and
one standard output file, the simultaneous
output of a compiler list-
ing and code for later execution was only possible by treating the listing as comments to the assembler
(compare later remarks on the
restriction of only one output file). 4. The byte manipulation
facilities
of the PDP-IO considerably simpli-
fied the implementation of PACKED RECORD and PACKED ARRAY ~I .. 10~ OF CHAR which enables us to use only two words to store identifiers with up to ten characters. Without implementing PACKED we would have run into core storage bottlenecks on our installation.
However,
char-
acter strings other than identifiers
are not yet packed:
this would
require a nonstandard PACK procedure
since the size of other strings
107
is only detected at execution time and not fixed in a declaration. (See later remarks.)
A detailed discussion of the decisions that resulted in the current compiler version for the DEC-System I0 can be found in (14). The bootstrap of the PDP-IO version proceeded according to the following diagram where the
[PAC4L /¢4cRo' .........
~
t PA~'~/-
....
IPA~C/4I"IPA~CAL ~
,,SC
W' assembly run (MACRO-IO into PDP-IO machine code) has been suppressed. Without
optimization of the PDP-IO code generation the compilation of
the compiler can be executed within
110 seconds of a dedicated PDP-!O,
to be compared to 600 seconds needed to obtain the same compilation by interpreting the SC version of a compiler generating code for the PDP10. Replacing the code generation for the SC by that for the PDP-IO has somewhat increased the size and compile time. The PDP-IO version requires at the moment 5 k words for runtime time support and I/O buffers,
stack, 2 k words for run-
4.5 k words for global variables,
24.5 k words for code and constants,
and
at a total of 36 k words.
The next steps are: - converting to 7-bit-ASCII
code as internal character representation;
- writing a new runtime support to provide I/0-capabilities
for arbi-
trary files, not only for the standard files INPUT and OUTPUT as in the compiler version obtained from ETH ZUrich; -
providing means to communicate via a typewriter terminal,
something
which is not asked or implemented in a batch processing environment but of great importance in a timesharing environment DEC-System 10;
as given by the
108
- output directly is immediately - optimization
executable,
absolute
code which after the compilation
loaded and started;
by redesign
of analysis
and code generation
for expres-
sions.
IV The clarity and formulating power of the p r o g r a m m i n g
language
together with the well structured
by U. Ammann have
very favourably
influenced
cope with several adverse the p a r t i c i p a t i n g
compiler developed
this b o o t s t r a p p i n g circumstances
students
nobody at our institute
had no practZcal
this b o o t s t r a p p i n g
experience
experience
in compiler
of this size;
in PASCAL or in MACRO-tO;
had seen the new compiler when we decided
on
project.
Based on the experience
gained during the realization
process we would like to discuss
some modifications
which we started in order to improve can be organized
since we had to
in a short period:
building or handling a p r o g r a m m i n g project - they had no p r o g r a m m i n g
project,
PASCAL
to the system from
its portability.
in three areas which a~e almost
of this bootstrap
Our suggestions
independent
from each
other: I. The stack computer and the SC version of the compiler. 2. The PASCAL version of the new compiler as far as no modifications to the definition 3. Considerations
of the language
PASCAL are implied.
to modify the PASCAL definition.
Ad i: Modifications
to SC and SC compiler
version
i.I The SC should not rely on word sizes greater than, e.g., internal representation 1.2 Any unavoidable
modifications
would be considerably with symbolic one absolutely ing phase"
to the SC object
code of the compiler
to labels rather than as
Since the SC employs
the character representation
representation, unreasonable
the realization overhead
anyway a "load-
of the SC code of this suggestion
(see section
the SC outputs either a compiler can be loaded and executed.
choose between two compilation
passes
II).
listing and SC code -
case the SC code cannot be loaded and executed
SC code which
32 bits for
II).
eased if the SC code could be written out
addressed block.
to convert
into its internal
in which
(see section
branch addresses referring
might not introduce 1.3 At present,
of data
This
- or only
forces the user to
or not getting e compiler
Io9
listing.
If the SC loader could recognize
a "comment" symbol and
every line of compiler listing would be preceeded by such a comment symbol,
this unfortunate
alternative
can easily be avoided.
Ad 2: Changes in the new PASCAL compiler requiring no modifications to the language definition. 2.1 The dependence
of the compiler on the order of character symbols
in the code used for internal representation explicit.
should be made more
This includes defining and initialising all arrays for
at least a full 64 character
set regardless
of its internal order-
ing. In addition the compiler logic for handling SETs should be parametrized in such a way that even transfer to the 7-bit-ASCi! code should be possible as far as it is restricted to the use of those characters that are also contained in the 6-bit-ASCl! subset. The realization of the CASE statement
in the PASCAL compiler
is a nice example that such an approach is indeed possible. 2.2 Since the majority of presently
available
computer architectures
support direct operand combinations between registers code generation for expressions
and memory~
should be delayed as long as pos-
sible to obtain enough information for the proper choice of instructions
(3). Being able to model code generation for these computers
according to better suited code generation
for an intermediate ma-
chine would considerably ease the transfer of such a compiler.
Now
one is forced to choose between complete redesign of the corresponding parts in the compiler for optimizing the generated code or to accept quite inefficient
and voluminous
code - if this ap-
proach is feasible at all.
Ad 3: Modifying the PASCAL definition to improve portability. 3.1 The new compiler - as it is obtained from Z~rich - has only the standard INPUT and OUTPUT files implemented
- necessitating out-
put of compiler listing and generated code on the same file. Incorporating the compiler listing as comments in the code output for the MACRO-IO assembler this disadvantage
somewhat.
(compare
1.3 of this section) eases
Still a high price has to be paid: as-
sembly of this output file from a compilation of the compiler itself requires
about 6 minutes on a dedicated PDP-IO
(three times
more than to compile with the PDP-IO version of the PASCAL compiler!) and about 35-40 minutes to print the resulting list with a 1100 line per minute printer.
This results from the input format
required by the MACRO-IO assembler,
namely one instruction per
line. Abusing some PASCAL features we enforced a second output file
110
in order to be able to separately write code for a s s e m b l e r input and a compiler listing t o g e t h e r with a compressed format
for the gene-
rated code. R e d u c i n g the print time by more than a factor three to less than 10 minutes d e s t r o y e d a considerable p s y c h o l o g i c a l barrier to obtain and inspect the current compiler output listing during d e b u g g i n g runs.
This p r o b l e m is b a s i c a l l y due to the fact that the current version of PASCAL allows the formatted input/output procedures
READ and
WRITE only for the standard files INPUT and OUTPUT, respectively. It should be easy to include an optional file s p e c i f i c a t i o n into these p r o c e d u r e s
in order to use t h e m for other files as well.
Al-
though it is in p r i n c i p l e possible to access other files by means of the standard procedures
GET and PUT, these are not i m p l e m e n t e d
in the new compiler from which we bootstrapped.
In addition - their
use requires more effort to obtain the f o r m a t t i n g features that are available in READ and WRITE. 3.2 As a corollary to the p r e c e e d i n g point: why are n o n s t a n d a r d procedure argument
conventions n e c e s s a r y for formatted I/O? One could
argue: the standard argument
conventions
are not general or power-
ful enough to account for a situation which apparently occurs so often that specific n o n - s t a n d a r d
conventions have to be introduced.
3.3 The r e s t r i c t e d memory c o n f i g u r a t i o n of our i n s t a l l a t i o n forced us to make use of the PACKED option at an early stage in the b o o t s t r a p process.
Here again we were r e s t r i c t e d from p a c k i n g general strings
- as they occur, e.g., in arguments to READ and WRITE - due to the narrow d e f i n i t i o n of the standard procedure
PACK which accepts only
arrays of characters with a size fixed at d e c l a r a t i o n time, 3.4 Considerable
space could be saved if it would be possible to ini-
tialize globally declared variables
at compile
time - a feature
w h i c h is available in the first PASCAL compiler on a trial basis, but not included in the revised report on PASCAL. 3.5 A l t h o u g h the PACKED RECORD feature enables one to generate a full PDP-IO i n s t r u c t i o n without recourse to assembly
language routines,
the lack of a proper t r a n s f e r function forbids to append full word instructions
and constants of type real, integer etc.
single output
file: the "variant" record concept
here since no space is available in the object field variable. as possible
onto one
cannot be used
code file for a tag-
If the language should allow to formulate
of the compiler r e q u i r e m e n t s
as much
in PASCAL itself - thus
r e d u c i n g the size of a runtime support to be d e v e l o p e d specifically for each i n s t a l l a t i o n - then t r a n s f e r procedure
of the follow-
111
ing kind is necessary: PACKEDWORD
(VAR RESULTWORD:INTEGER; no type declaration~
VAR NANEOFDATASTRUCTURE
;
POSITIONOFWORD:INTEGER); This would pick the word, the data structure
indicated by the third argument,
indicated
by the second argument
of its type - and return it as an integer obvious that a procedure same argument Moreover, assembly
applies
to standard
environment
communicate
it is important
different
call of an
to be able to
- and still access a standard
from the terminal
like GETLN,
etc. to allow formatted
I/O. Therefore
PUTLN
- as well as
(10) - as READTTY,
!/0 from terminals.
will be added to terminate
in his answer
CHR and ORD.
the READ and WRITE procedures
the other standard procedures
out a "earriage
like
to a nonstandard
over terminals
INPUT and OUTPUT file
procedure
procedures
It is
- but the
procedure.
we intend to reproduce WRITETTY
in RESULTWORD.
on the implementation
it is still preferable language
3.6 In a timesharing directly
depends
from
- regardless
return - line feed"
output
A BREAKLN
to the terminal
with-
in order to let the user type
on the same line on which a question has been
written by the program
(15).
V We thank Prof. N° Wirth and Mr. U. Ammann for the v e r y generous helpful
cooperation
project
up to the stage described
The NACRO-IO
that enabled us to smoothly advance
interpreter
(G.F.) with v e r y engaged
Behrens
contributed
heavily
support
of the compiler.
to the problems
connected
H.-H.
Brockmann
that all these System
runtime
Mr. H.-E.
10 when they accepted
like to extend our gratitude
of the SC
for the NACRO-IO
from 0DC- to ASCII-
has been developed
- a considerable
Mr. M.
Sengler has drawn our attention
piece
and debugged by Mr.
of work in v i e w of the fact
students had no experience
but for their enthusiasm
support
with the conversion
code. The CDC 6000 ~imulator
by one of the
from Mr. D. Friede.
in getting the "SET problems"
solved and sketched a preliminary version
with our
in this report.
for the SC has been developed
authors
and
whatsoever
their respective
tasks.
with the DECWe would
to them not only for their contribution
and interest
with which they engaged
112
themselves. One of the authors (H.-H. N.) gratefully acknowledges a discussion with Prof. F. Schwenkel en the subject of this report.
Literaturhinweise (I) Wirth, N., The Programming Language PASCAL: Acta Informatica I, 35 (1971) and (Revised Report) Berichte der Fachgruppe Comput~rwissenschaften der ETH ZUrich, Nr. 5 (Juli 1973) (2) ~ m a n n , U., The Nethod of Structured Programming Applied to the Development of a Compiler: Proceedings of the A~ff International Computing Symposium, Davos (4.-7. Sept. 1973) (3) Welsh, J., Quinn, C., A PASCAL Compiler for ICL 1900 Series Computers: Software-Practice and Experience ~, 73 (1972) (4) Schild, R., Implementation of the Programming Language PASCAL: Proceedings of the I. GI Fachtagung ~ber Programmiersprachen MiJ~chen ~,{arch 71 and Lecture Notes in Economics and Nathematical Systems, vol 75 (1972)~ p. I, Springer Verlag, Berlin Heidelberg - New York (5) Wirth, N., The Design of a PASCAL Compiler: Software-Practice and Experience ~, 309 (1971) (6) Brockmamn, H.-H., Friesland, G., Habermann, H.-J., Lorenz, F.-W., Nagel, H.-H., Sengler~ H.-E., Stirl, P.J., Ein PASCAL Compiler f~r die PDP 10, Bericht ~ber eine Gruppenstudienarbeit: Nitteilung Nr. 2 des Instituts f~r Informatik der Universit~t Hamburg (Mai 1973) (7) see e.g. - Poole, P.C., Waite, W.N., Portability and Adaptability: Advanced Course on Software Engineering (F.L. Bauer, ed.) and Lecture Notes in Economics and Nathematical Systems vol 81 (1973), pJ83, Springer Verlag, Berlin - Heidelberg - New York Bauer, F.L., Software Engineering: Proceedings of IFIP Congress 1971, (C.V. Freimann, ed.), North-Holland Publ. Co., Amsterdam 1972, p. 530 (8) private communications by Mr. U. Ammann and Mr. N. Wirth, see also (2) (9) Earley, J., Sturgis, H., A Formalism for Translator Interactions: C A ~ 13, 607 (1970) and the literature quoted therein (10) Wirth, N., Implementations of PASCAL in systems using character sets without control characters (ETH Z~rich, note of June 26, 1973) (revised October 30, 73) -
113
(11
(12
13 -T4) 15)
Desjardins, P., A PASCAL compiler for the XEROX Sigma 6: AC~ SIGPLAN Notices ~, No. 6, p. 37 (June 73) 0rganick, E.I., Cleary, J.G., A Data Structure Model of the B 6700 Compu~r System: Proc. S2~iposium on Data Structures in Programming Languages (J.T. Tou ~. Wegner, eds.), ACM SIGPLAN Notices ~, No. 2, p. 83 (Febr. ~I Wirth, N., On "PASCAL", Code Generation, and the CDC 6000 Computer: Computer Science Department, Stanford University, STAN-CS-72-257 (Febr.72) Lorenz, F.-W., Stirl, P.J., Diplomarbeit: Institut fttr Informatik, Hamburg (in Vorbereitung) 1973 This is modelled after a corresponding feature in the DECSystem 10 ALGOL 60 version
Anschrift des Verfassers: Professor Dr. Hans-He]imut Nagel, Institut f~r Informatik der Universit~t Hamburg, 2 Hamburg 13, Schl~terstr. 70
ERFAHRUNGEN MIT EINEM PARSER-GENERATOR FOR CHOMSKY-GRAMMATIKEN R. NOLLMANN
O. E i n l e i t u n ~ J.
Eickel
und M. Paul haben in [EP] einen A l g o r i t h m u s
der das A n a l y s e - und M e h r d e u t i g k e i t s p r o b l e m tiken untersucht. W e s e n t l i c h bei dem V e r f a h r e n i s t einer bottum-up-Analyse vornherein
vorgestellt,
bei Chomsky(-o)-Gramma-
der Gedanke, S c h w i e r i g k e i t e n
bei
dadurch zu vermeiden, da~ man sich n i c h t
auf eine bestimmte A n a l y s e - S t r a t e g i e
festlegt,
von
also i n s -
besondere auch v o n d e r Ublichen L i n k s - R e c h t s - S t r a t e g i e a b w e i c h t . Auch s o l l e n I n f o r m a t i o n e n , wie S c h w i e r i g k e i t e n zu beheben s i n d , n i c h t erst
zur L a u f z e i t
des Parsers gesammelt werden, sondern in einem
Parser-Generator-Lauf.
Die e r z e u g t e n L i s t e n
sollen
m~glichst
klein
sein. Der Parser s o l l
dabei wie f o l g t
arbeiten:
Die Analyse kann in mehreren " L ~ u f e n " d u r c h g e f U h r t werden. Dabei werden in einem " L a u f " j e w e i l s duziert,
"schwer" a n a l y s i e r b a r e
L~ufe a n a l y s i e r t
Teile
werden, wobei g e h o f f t
erkannter Teilstrukturen
Chomsky(-o)-Sprachen
analysierbare
Teile
re-
sollen
in einem der n~chsten
wird,
da~ auf Grund b e r e i t s
d i e Analyse dann weniger schwer sein w i r d .
Wegen der U n e n t s c h e i d b a r k e i t fur
nur " l e i c h t "
des Wort- und M e h r d e u t i g k e i t s p r o b l e m s
kann das V e r f a h r e n von Eickel
und Paul nur
ein Versuch s e i n , bei konkreten Grammatiken diese Fragen ( t e i l w e i s e ) beantworten zu l a s s e n . Der P a r s e r - G e n e r a t o r u n t e r s u c h t den s t r u k turellen
Zusammenhang e i n e r v o r g e l e g t e n Sprache. Dadurch e r h ~ I t
der
S p r a c h e n t w e r f e r w i c h t i g e Hinweise auf E i g e n s c h a f t e n der Sprache ( e r k a n n t e M e h r d e u t i g k e i t e n , S a c k g a s s e n f r e i h e i t bzw. - a r m u t , s t r u k t u r e l l e K o m p l e x i t ~ t ) , dem I m p l e m e n t i e r e r w i r d die K o n s t r u k t i o n der Obergangslisten erleichtert oder ganz abgenommen. W~hrend d i e Syntax von Programmiersprachen
U b l i c h e r w e i s e mit H i l f e
kontextfreier
t i k e n b e s c h r i e b e n w i r d , lassen sich mit H i l f e von a l l g e m e i n e n Chomsky-Grammatiken Optimierungen in der N~he der Q u e l l s p r a c h e auch der Z i e l s p r a c h e b e s c h r e i b e n .
Grammaals
115
1. Der Parser-Generator Der Parser-Generator untersucht den strukturellen Zusammenhang einer gegebenen Chomsky-Grammatik. Er soll dabei erkennen, ob es in der Grammatik Mehrdeutigkeiten und kritische Regeln gibt. Kritische Regeln, d.h. Regeln, die bei einer bottum-up-Analyse in Sackgassen fUhren k~nnen, sollen unkritisch gemacht werden. Der Parser-Generator transformiert dazu die Grammatik s c h r i t t weise in eine sackgassen~rmere Grammatik, indem er zu kritischen Regeln innerhalb vorgegebener Schranken Links- und/oder Rechtskontext konstruiert. 1.1 Beschreibung des Verfahrens Yon der zu untersuchenden Grammatik G = (A, T, P, S) mu8 das Produktionensystem P in BNF-Schreibweise vorliegen. Die Menge A der Alphabetelemente wird aus dem Produktionensystem bestimmt. Angaben zum terminalen
Zeichenvorrat T und zur Menge S der
Axiome sind nicht notwendig. Die Axiome sollen jedoch maximal sein, d.h. zu keinem Axiom s E S gibt es eine Produktion, so da~ gilt a::=bsd. Oberdies soll die Grammatik eine "Grammatik mit Randzeichen~ " sein. 1.1.1Zun~chst wird die folgende einfache Transformation vorgenommen: T r i t t ein Alphabetelement X(A mehr als einmal in den rechten Seiten des Produktionensystems auf, so wird fur jedes Auftreten yon X dem Alphabet ein X~A hinzugefUgt, das ( k r i t i s c h e ) Alphabetelement X wird an der Fundstelle durch das (unkritische) X' ersetzt und schlieBlich wird dem Produktionensystem P die ( k r i t i sche) Produktion X'::=X hinzugefUgt.
Die Menge der auf diese Art
erzeugten Regeln wird Menge der kritischen Regeln genannt: Regeln dieser Menge k~nnen der Beginn von Mehrdeutigkeiten oder Sackgassen sein. 1.1.2 Nach dieser einfachen Transformation wird das Alphabet in disjunkte Teilmengen zerlegt: A
:
AL
v
Ak
~
A'
~
~u
A-
A~
wobei g i l t : Az i s t die Menge der Alphabetelemente, die im Produktionensystem nut auf den linken Seiten auftreten (Axiom, Antiterminal-Elemente);
116
Ak
ist
die Menge der k r i t i s c h e n
Alphabetelemente;
A'
ist
die Menge der u n k r i t i s c h e n
Alphabetelemente,
die ein-
z i g e s A l p h a b e t e l e m e n t der r e c h t e n S e i t e e i n e r P r o d u k t i o n sind; ist
d i e Menge der A l p h a b e t e l e m e n t e ,
einer Produktion ist
A-
ist
beginnen;
die Menge der A l p h a b e t e l e m e n t e ,
einer Produktion
die eine r e c h t e S e i t e
die eine r e c h t e S e i t e
beenden;
die Menge der A l p h a b e t e l e m e n t e ,
S e i t e e i n e r P r o d u k t i o n weder e r s t e s
die
in e i n e r r e c h t e n
noch l e t z t e s
Element
sind. Mit Hilfe
d i e s e r Zerlegung l ~ B t sich die z w e i s t e l l i g e
Relation
definieren: Sei X, Y £ A. Es g e l t e
X~ Y
genau dann, wenn eine der f o l -
genden Bedingungen g i l t : I)
XE ~
~
A-,
2)
X E A~ ,
3)
Es gibt kein
Y ~ A~ Y ~ A- ~ A/ p E P, so dan g i l t :
p=(a::=alXYa2)
Mit H i l f e der Relation ~ l~Bt sich schnell und einfach prUfen, ob eine vorgelegte Zeichenreihe (String) "unzul~ssig" i s t . Diese PrUfung e r f o l g t " s t a t i s c h " , d.h. ohne reduzierendes ("dynamisches") Anwenden von Produktionen. Eine "nicht unzul~ssige" Zeichenreihe kann durch (mehrmaliges)
Reduzieren als "syntaktisch falsch" er-
kannt werden. Der Analysealgorithmus prUft bei zwei benachbarten Alphabetelementen j e w e i l s , ob die Relation ~ e r f U l l t i s t oder nicht. Diese PrUfung i s t besonders nach k r i t i s c h e n Reduktionen w i c h t i g , um unzul~ssige Zeichenreihen zu eliminieren. 1.1.3 Mit Hilfe was ein a)
der Zerlegung des Alphabetes l ~ B t "offener"
bzw. ein
sich l e i c h t
"abgeschlossener" String
sagen,
ist:
Ein S t r i n g X = X l . . . XnEA + (A+: f r e i e Halbgruppe Uber A b z g l . der K o n k a t e n a t i o n ) h e i B t o f f e n , wenn (mindestens) eine der f o l g e n d e n Bedingungen e r f U l l t a.1)
XIE Ai ~ A-
a.2)
Xn~A- v
Ax.
ist:
117
b)
Ein S t r i n g
C)
Ein S t r i n g
x ~ A+
h e i B t abgeschlossen, wenn x£ (AZ) + g i l t .
X:XlooOXnEA+
heiBt links
(rechts)
abgeschlossen,
wenn XI~A± (Xn~A x) g i l t . Nun wird e i n " R e d u k t i o n s s c h r i t t I)
f u r einen S t r i n g "
FUhre in dem zu a n a l y s i e r e n d e n S t r i n g
(von l i n k s
oder umgekehrt gehend) an j e d e r S t e l l e , kritische
Reduktion mSglich i s t ,
erkl~rt: nach r e c h t s
an der eine n i c h t -
diese Reduktionen aus.
F a l l s der S t r i n g dann weder o f f e n noch abgeschlossen i s t mindestens eine n i c h t - k r i t i s c h e wiederhole I). 2)
Reduktion m~glich war,
Andernfalls:
FUhre an j e d e r m~glichen S t e l l e ,
an der eine k r i t i s c h e
t i o n m~glich i s t ,
Reduktionen aus. Z~hle den
die k r i t i s c h e n
R e d u k t i o n s z ~ h l e r dieses S t r i n g s 3)
und
um I hoch.
Reduziere in jedem der r e d u z i e r t e n S t r i n g s an der eine n i c h t - k r i t i s c h e
Reduk-
an j e d e r S t e l l e ,
Reduktion m~glich i s t .
Wiederhole
bei jedem der U b r i g b l e i b e n d e n n i c h t u n z u l ~ s s i g e n S t r i n g s nicht-kritische
Reduktionen, b i s der S t r i n g entweder o f f e n
oder abgeschlossen i s t
oder b i s keine w e i t e r e n i c h t - k r i t i s c h e
Reduktion mehr m~glich i s t . Bern. :
Im T e i l s c h r i t t
2) entstehen h ~ u f i g S t r i n g s ,
der R e l a t i o n
~
werden mUssen. Deshalb i s t
der T e i l s c h r i t t
Einsparung von Speicher besonders w i c h t i g . z.B.,
wenn f u r
i
kritische
Ersetzungen m~glich s i n d , 1.1,4 Z i e l
des Verfahrens
ist
bedingungen zu f i n d e n .
bedeuten, dab
3) wegen der Es entstehen
Elemente j e w e i l s
kl'k2"...'ki
es, zu k r i t i s c h e n
K. 1 neue S t r i n g s .
Produktionen
Kontext-
Die Schreibweise >
sol]
die auf Grund
u n z u l ~ s s i g sind und deshalb e n t f e r n t
X
zu
X'
x
reduziert
werden kann, wenn der
L i n k s k o n t e x t a E A+ und der R e c h t s k o n t e x t bE A+ vorhanden i s t ; dann kann
aXb zu aX'b
Das gewUnschte Z i e l
und
ist
aX'b
erreicht,
zu x ~
A+ r e d u z i e r t
wenn es zu dem L i n k s k o n t e x t a
und dem R e c h t s k o n t e x t b nur eine anwendbare k r i t i s c h e X'::=X gibt. Aus der ( u n e n d l i c h e n )
werden.
Produktion
Menge m ~ g l i c h e r , im Sinne der R e l a t i o n
n i c h t u n z u l ~ s s i g e r K o n t e x t e w i r d genau ein Element ausgew~hlt:
118
O.B.d.A sei x=XI...X n rechts offen, d.h. an x kann rechts Kontext angefUgt werden. Dann gibt es n~mlich ein Y ~ A und eine Produktion p ( P, so dab p=(a::=alXnYa2) (und damit auch Xn ~ Y) g i l t . Dann i s t Ya2 der gesuchte Kontext. {Dieser Kontext wird gelegentlich auch Grundkontext genannt, im Gegensatz zu den Kontexten, die sp~ter auf andere Art k o n s t r u i e r t werden.) Linkskontext wird analog gefunden. Nach dem Anh~ngen yon Kontext hat man Strings, die weder offen noch abgeschlossen sind. Durch weitere Reduktionsschritte fur Strings wird versucht, sie zu offenen oder abgeschlossenen Strings zu reduzieren. Die I t e r a t i o n s v o r s c h r i f t zur Kontextsuche fur die k r i t i s c h e Produktion X'::=X l a u t e t demnach (ohne Abbrech-Kriterium):
~i]
X'::=X
[bi]
~
xi
I
~
fur i = 0 , i , 2 . . . . .
[ai+ ~ X'::=X [ b i + 1 ] - - - > wobei ao:=e,
bo:=e
und
Xo::X~
xi+ 1
zu setzen i s t (e i s t der leere
String).
Es g i l t : I
a ~i + l a i
falls
xi
links offen
ai
falls
xi
links abgeschlossen und noch kein Randzeichen angefUgt {~t
ai
sonst
ai+l =
bi+l
bi b' i+I
falls
xi
rechts offen
bi ~
falls
xi
rechts abgeschlossen und noch kein Randzeichen angefUgt i s t
bi
sonst
119
falls
links
xib~ i + l
falls
rechts
a' i + i x i b ~ i÷i
falls
links
xi
sonst
a'i+lX i
Xi+l
1.1.5
offen
offen und r e c h t s
Wir haben im l e t z t e n A b s c h n i t t a n g e d e u t e t , wann d i e zu einem k r i t i s c h e n Element beendet werden kann. Zun~chst
sagen w i r ,
zwei S t r i n g s
a)
was u n t e r
Kontextsuche
und R e c h t s d u r c h s c h n i t t verstanden
XflLy
: :
e
falls
j = o
x
falls
j : n
y
falls
j : m
x ...xj i
sonst
Linksdurchschnitt
Dann h e i B t
I
in
yon x und y.
Sei j d i e maximale Anzahl d e r j e n i g e n A l p h a b e t e l e m e n t e , denen x und y vom Ende her Ubereinstimmen.
xr~Ry : =
von
werden s o l l :
Sei j die maximale Anzahl d e r j e n i g e n A l p h a b e t e l e m e n t e , denen x und y vom Anfang her Ubereinstimmen. Dann h e i B t (e sei der l e e r e S t r i n g ) I
b)
Links-
x : X I . . . X n und y = Y l . . . Y m
offen
F e
falls
j = o
x
falls
j = n
y
falls
j = m
Xn_j+l...x Rechtsdurchschnitt
n
von x und y .
sonst
in
120
Damit lassen s i c h d i e f o l g e n d e n D e f i n i t i o n e n c)
geben:
Die Kontextabh~ngigen P r o d u k t i o n e n
[c] Y'::=Y ~ ] - - - > y heiBen kompatibel, wenn die folgenden Bedingungen gelten:
d)
c.i)
x = v
C.2)
X~ Y~
C,3)
ar~Rc = a
oder
a ~R c :
c.4)
b ~L d = b
oder
b nLd : d
Eine k o n t e x t a b h ~ n g i g e P r o d u k t i o n ihr
e)
keine k o m p a t i b l e
c
heiBt eindeutig,
kontextabh~ngige Produktion
wenn es zu gibt.
Eine kontextabh~ngige Produktion [a] X ' : : = X [ b ] - - - ~ x ' ,
x'~(A~) +
heist mehrdeutig, wenn es zu i h r eine kompa t i b l e kontextabh~ngige Produktion [a']X'~::=X [b']---~ x ' ' ,
x''E(A L) +
gibt. f)
Eine kontextabh~ngige Produktion heiBt k r i t i s c h , wenn sie weder eindeutig noch mehrdeutig i s t ,
Damit k~nnen w i r sagen: Die Kontextsuche zu e i n e r k r i t i s c h e n als e i n d e u t i g
Produktion
oder mehrdeutig e r k a n n t
Wegen der g e n e r e l l e n U n m ~ g l i c h k e i t ,
e n d e t , wenn sie
ist,
einen A l g o r i t h m u s
anzugeben,
der das Wort- bzw. das M e h r d e u t i g k e i t s p r o b l e m f u r ChomskySprachen l ~ s t , wird bei E r r e i c h e n der vorgegebenen Schranke f u r d i e K o n t e x t l ~ n g e oder f u r d i e Anzahl der R e d u k t i o n s s c h r i t t e f u r S t r i n g s d i e Kontextsuche zu der b e t r e f f e n d e n k r i t i s c h e n P r o d u k t i o n eingestellt. Diese P r o d u k t i o n kann also bei sp~teren P a r s e r l ~ u f e n in Sackgassen ( " b a c k - u p " )
oder in M e h r d e u t i g k e i t e n
fUhren.
!21
1.1.6 I s t fur alle kritischen Produktionen die Kontextsuche beendet worden, so i s t es notwendig, den gewonnenen Kontext zu begutachten, um notwendigen yon unn~tigem Kontext zu unterscheiden+ Nicht notwendiger Kontext einer kontextabh~ngigen Produktion kann gestrichen werden. Er wUrde den Parser nur belasten. Notwendig soll ein Kontext dann sein, wenn er gerade noch sichert, dab die kontextabh~ngige Produktion nicht kompatibel wird. Ein einfacher Ansatz zu einer Kontextverminderung ergibt sich aus folgender Oberlegung: Zu der kontextabh~ngigen Produktion
jail
Xi::=X[bi]
>
xi
betrachte man die Rechtsdurchschnitte ai ~Ral und die Linksdurchschnitte bi ~Lbj mit allen kontextabh~ngigen Produktionen [aj] Xj::=X[bj] fur die
Xi $ Xj
,, x j ,
gilt.
Unter diesen Rechts- und Linksdurchschnitten w~hlt man die j e weils l~ngsten aus, z.B. a j l und bj2. Dann g i l t ( Ixl bedeute L~nge von x ) :
Falls
lajll
aX'BI...BjCi+I...CmY'd
ein w e i t e r e r
Kontext zu X ' : : = X .
Ein w e i t e r e r
K o n t e x t zu Y ' : : = Y
[aXBI...BjCi+I...Cm]
Y':::YEd]
ist ) a×'BI...BjCi+I...CmY'd.
1 . 1 . 8 Die im l e t z t e n S c h r i t t e r z e u g t e n Kontexbedingungen ( " F a l t u n g e n " ) werden m ~ g l i c h s t g e k U r z t und m i t den b i s h e r gewonnenen Kontexten verglichen,
Wurden K o n t e x t e mehrfach e r z e u g t ,
so werden s i e bis
auf ein Exemplar g e s t r i c h e n . Wurden k o m p a t i b l e
Kontexte e r z e u g t ,
so wird
f u r d i e s e Elemente
w e i t e r e r K o n t e x t g e s u c h t . Das e r w e i t e r t e Kontextsystem w i r d weiterhin gefaltet, bis entweder durch F a l t e n keine neuen Kontexte e r z e u g t werden oder die b e r e i t s werden.
genannten Schranken e r r e i c h t
123
1.2 Schwierigkeiten Bisher wurden die wesentlichen Teile des Algorithmus
be-
schrieben. Bei der Implementierung des Generators traten f o l gende Probleme auf: a)
Wie kann der Speicher- und Zeitbedarf klein gehalten werden?
b)
Wie wird die Kontextsuche zweckm~Big gesteuert? (Bisher wurde l e d i g l i c h gesagt, da~ zu kompatiblen kontextabh~ngigen Produktionen Kontext gesucht wird.)
c)
Wie sollen zyklische Reduktionen und zyklische Kont~xte behandelt werden?
1.2.1Bei der Beschreibung eines Reduktionsschrittes fur einen String wurde bereits gesagt, yon welcher Gr~Benordnung die Anzahl der Strings i s t , die durch Ersetzung k r i t i s c h e r Alphabetelemente entstehen. Die angegebene Reduktionsvorschrift s t e l l t sicher, dab gerade diese kritischen Reduktionen unter Kontrolle bleiben. Nicht-kritische Ersetzungen sind (sofern sie nicht zyklisch zu l~ngeren reduzierten Strings fUhren) unbedeutend fur den Speicherbedarf. Das bisher p r a k t i z i e r t e Verfahren, alle m~glichen kritischen Reduktionen auszufUhren, i s t einfach, aber speicheraufwendig:
Ein menschlicher "Reduzierer" "sieht" viel
h~ufiger, wo eine oder auch mehrere kritische Reduktionen nUtzlich sein k6nnten. Der Mensch l e r n t aus der vom Generator ausgegebenen Reduktions-"Geschichte", welche kritischen Reduktionen ausgew~hlt werden mUssen, um Verzweigungen der Reduktion zu vermeiden. Der Reduktionsalgorithmus wird im wesentlichen so m o d i f i z i e r t : Sind bereits eindeutige oder mehrdeutige kontextabh~ngige Produktionen erkannt, so k6nnen sie angewendet werden, f a l l s an der Anwendungsstelle der entsprechende Kontext gefunden wird. Andernfalls mUssen wiederum a l l e m~glichen F~lle "durchprobiert" werden oder aber der menschliche Berater wird gefragt. Die Tatsache, dab alle M6glichkeiten "durchprobiert" werden, weist darauf hin, dab das System von Kontextbedingungen (noch) unvollst~ndig i s t . Es i s t w~hrend der Grundkontextsuche sehr unvollst~ndig, durch die (m~glicherweise fortgesetzten) Faltungen soll dann eine Vervollst~ndigung erreicht werden.
124
Die V o l l s t ~ n d i g k e i t ist
des (kontextabh~ngigen)
Voraussetzung f u r
seine Verwendbarkeit
Produktionensystems im Parser.
Denn
wird bei v o l l s t ~ n d i g e m Produktionensystem zu einem k r i t i s c h e n Alphabetelement kein entsprechender Kontext gefunden, so i s t der zu analysierende S t r i n g s y n t a k t i s c h f a l s c h . 1.2.2 Es i s t s i c h e r l i c h n i c h t s i n n v o l l , zu a l l e n kompatiblen k o n t e x t abh~ngigen Produktionen weiteren Kontext zu suchen, wie es etwa durch die Symmetrie der R e l a t i o n "Kompatibel" nahegelegt w i r d . Bei der weiteren Kontextsuche i s t der b e r e i t s vorhandene Kontext zu b e r U c k s i c h t i g e n .
Seien ki :: ~ i ] Xi:::X [bi] ~ x i (i~2) kompatible kontextabh~ngige Produktionen. Man bestimme die Mengen
]ki:a nRai:a "
K':= [k I K": =
[k
I
kj:bnLbj=b}
]ki:a /~IRai=a v ]kj:b {~Lbj:b }
Die Menge K' kann aufgefaSt werden als Menge k o m p a t i b l e r Produktionen m i t " u n t e r e n t w i c k e l t e m " Kontext, die Menge K" als Menge kompa t i b l e r Produktionen mit " a n d e r s " , h~ufig "gegenl~ufig" Beispiel:
entwickeltem
1) Zu
Kontext.
[BC]X~::=X[DE]~
x ~ ist x"
i°e
Produktion mit unterentwickeltem Kontext. 2) In den kompatiblen
Produktionen
[~X'::=X[e]
~
x ' und
[ e ] X " : ::X ~ ]
-----~ x"
sind die Kontexte gegenl~ufig AIs gUnstig hat sich erwiesen, zuerst weiterzuentwickeln:
entwickelt.
die u n t e r e n t w i c k e l t e n
Kontexte
!25
Falls
K' ~ ~
gilt,
so suche man nur f u r d i e
kompatiblen Produktionen aus andernfalls aus
K'
Kontext;
f u r d i e kompatiblen Produktionen
K"
Durch d i e s e V e r f a h r e n s w e i s e kann e b e n f a l l s der S p e i c h e r b e d a r f v e r m i n d e r t werden, w e i l Elementen aus 1.2.3
K'
kritische
bzw.
K"
Reduktionen nur bei den
d u r c h g e f U h r t werden.
Z y k l i s c h e Reduktionen und z y k l i s c h e Kontexte werden r i g o r o s behandelt:
Sobald eine z y k l i s c h e Reduktion oder ein z y k l i s c h e r
Kontext e r k a n n t w i r d , w i r d d i e b e t r e f f e n d e k r i t i s c h e entfernt,
wobei a l l e r d i n g s
system zu den k r i t i s c h e n nicht vollst~ndig
Produktion
v e r m e r k t w i r d , dab das K o n t e x t -
Produktionen
X.::=X m~glicherweise 1
wird.
Die Grundkontexte e n t s t e h e n auf z i e m l i c h e i n f a c h e A r t durch "~ffnen" ist
und "Kontextanh~ngen"
erreicht,
wenn nurmehr d i e Randzeichen erg~nzt werden
k~nnen. Das h e i s t aber, es s o l l ob es Kontexte ~a]
a
und
X'::=X
nicht entscheidbar. Zyklen g e f r a g t w i r d ,
1.2.3oi
b
v e r s u c h t werden, f e s t z u s t e l l e n ,
gibt,
[b ~]
Das Analyseproblem i s t
ziert
Das Ende d i e s e r Kontextsuche
so dab g i l t :
~ ~ z @ ,
aber f u r
z ~ (A~) +
a l l g e m e i n e Chomsky-Grammatiken
Dies wird h i e r nochmals erw~hnt, w e i l ob
u
zu
xuy
bzw.
xuy
zu
u
bei
redu-
werden kann.
Ein S t r i n g Linkskontext
a' E A'x(A'-) +
(bzw. b ' £ ( A - ) + xA')
heiBt z y k l i s c h e r
( R e c h t s k o n t e x t ) , wenn bei der Kontextsuche der
Linkskontext
a = a'
a ~ a"
(bzw. der R e c h t s k o n t e x t
b = b"b'b')
gefunden w i r d . Bei Chomsky-Grammatiken von Typ 2 und 3 bedeutet das, da~ es durch w e i t e r e s Uffnen die M ~ g l i c h k e i t g i b t , a l s Kontext anzufUgen.
Die M ~ g l i c h k e i t ,
wiederum
a'
(bzw, b ' )
bei e i n e r Verzweigung
immer wieder Kontext anfUgen zu k~nnen, v e r h i n d e r t
die ab-
schlieBende Reduktion a l l e r
z E (AZ) +
Verzweigungen auf ein
A n d e r e r s e i t s ergeben K o n t e x t e , d i e e r s t g a ~ n i c h t in den Zyklus fUhren oder aus ihm h e r a u s f U h r e n , n i c h t - k o m p a t i b l e n Kontexte.
h ~ u f i g d i e gewUnschten
126
Bei den anderen Typen von Chomsky-Grammatiken wird ohne RUcks i c h t auf d i e V o l l s t ~ n d i g k e i t
des erzeugten Systems von
Kontextbedingungen d a r a u f v e r z i c h t e t ,
Kontextbedingungen
w e i t e r z u e n t w i c k e l n , d i e mehr als einen Zyklus e n t h a l t e n . 1.2.3.2
Z y k l i s c h e Reduktionen, d i e keinen z y k l i s c h e n Kontext erzeugen, t r e t e n bei Chomsky-~ und -3-Typ-Grammatiken nur a u f , es zu einem
met
Ixil
X
: I
eine R e d u k t i o n s f o l g e
X--~ X1-->
...
Xn---~X ( n ~ l )
y'
weiterhin
gibt.
Werden bei Chomsky-O-Grammatiken S t r i n g s
x
x = x I Xx'x I x 2 oder x = X l y I y ' Y x 2 m i t x ' £ (A-) + x A~, X~A k , y ' ~ A \ x ( A - ) + ,
Y~A k
erzeugt,
falls
so wird angenommen, da# sich
x'
mit
bzw.
z y k l i s c h erzeugen l ~ B t . W e i t e r h i n w i r d angenommen, da~ d i e j e n i g e n Reduktionen, d i e nicht
in den Zyklus fUhren oder nach einmaligem D u r c h l a u f aus
ihm herausfUhren, genUgend I n f o r m a t i o n Uber d i e K o n t e x t bedingungen geben k~nnen. 1.3 Bemerkungen
zum Generator und zum erzeugten P r o d u k t i o n e n -
system Der G e n e r a t o r l a u f w i r d in v i e r F ~ l l e n w i l l k U r l i c h I)
Falls
"zyklische"
Reduktionen a u f t r e t e n ,
beeinfluBt:
wird die be-
treffende M~glichkeit eliminiert. 2)
Falls
"zyklischer"
Kontext a u f t r i t t ,
wird die b e t r e f -
fende M ~ g l i c h k e i t e l i m i n i e r t . 3)
F a l l s e i n R e d u k t i o n s z ~ h l e r eine vorgegebene Schranke erreicht,
w i r d d i e w e i t e r e Kontextsuche zu dem b e t r e f f e n d e n
Element e i n g e s t e l l t . 4)
Falls
eine K o n t e x t l ~ n g e
gebenen Wert e r r e i c h t , zu dem b e t r e f f e n d e n
( lal
+
Ibl
)
einen v o r g e -
wird e b e n f a l l s die Kontextsuche
Element e i n g e s t e l l t .
Durch diese MaBnahmen w i r d s i c h e r g e s t e l l t ,
dab der G e n e r a t o r -
l a u f f u r eine zu untersuchende Grammatik beendet wird und dab der S p r a c h e n t w e r f e r n U t z l i c h e Hinweise auf M~ngel der Sprachbeschreibung e r h ~ I t .
127
1.3.1 Durch die e r s t e n beiden MaBnahmen wird m ~ g l i c h e r w e i s e die Vollst~ndigkeit stellt.
des erzeugten Produktionensystems in Frage ge-
Die Frage, welche Auswirkungen das E l i m i n i e r e n h a t ,
kann der S p r a c h e n t w e r f e r ( v i e l l e i c h t ) Insbesondere i n t e r e s s i e r t
beantworten.
d i e Frage, ob das e r z e u g t e k o n t e x t -
abh~ngige Produktionensystem m ~ g l i c h e r w e i s e v e r s c h i e d e n e T e i l Produktionensysteme e n t h ~ I t , strategie-
die - mit geeigneter Analyse-
ein v o l l s t ~ n d i g e s
Produktionensystem ergeben.
F a l l s man e i n solches T e i l s y s t e m ausw~hlen k~nnte, w~re das Eliminieren unbedenklich.
Das Problem i s t
Chomsky-Grammatiken u n e n t s c h e i d b a r k e i t des Wortproblems).
jedoch f u r a l l g e m e i n e
(wegen der U n e n t s c h e i d b a r -
Bei P a r s e r l ~ u f e n w i r d h ~ u f i g b e o b a c h t e t ,
dab Regeln redundant s i n d ; d i e Redundanz b e z i e h t s i c h jedoch s t e t s auf d i e gew~hlte A n a l y s e s t r a t e g i e . Bei anderen A n a l y s e s t r a t e g i e n k~nnen andere Regeln redundant sein. 1.3.2 Der R e d u k t i o n s z ~ h l e r z ~ h l t w~hrend des G e n e r a t o r l a u f s , w i e v i e l e Reduktionsschritte fur kompatibler
Strings
(s.
1.1.3)
Kontext f u r eine k r i t i s c h e
n~tig sind,
bis n i c h t -
Produktion e r r e i c h t
ist.
Die Werte der R e d u k t i o n s z ~ h l e r erlauben eine Aussage Uber den strukturellen (In
Zusammenhang der zu untersuchenden Sprache.
[ E l w i r d eine Grammatik " s t r u k t u r e l l
nannt, wenn es Sackgassen g i b t ,
d.h.
d i e n i c h t auf ein Axiom f U h r e n . ) - ausgehend von den k r i t i s c h e n also s t r u k t u r e l l
generieren.
ge-
Und zwar weisen die Reduk-
t i o n s z ~ h l e r w e r t e auf den Aufwand h i n , freie,
zusammenh~ngend"
es g i b t R e d u k t i o n s f o l g e n , der notwendig war, um -
Produktionen - eine sackgassen-
n i c h t zusammenh~ngende Grammatik zu
Die R e d u k t i o n s z ~ h l e r w e r t e k~nnen auch auf d i e An-
zahl der K o n t e x t m ~ g l i c h k e i t e n h i n w e i s e n , d i e zu e i n e r k r i t i s c h e n P r o d u k t i o n zu f i n d e n s i n d . Bezogen auf den S p r a c h e n t w e r f e r bedeutet das, dab er den Aufwand bei der Analyse von S~tzen oder Programmen absch~tzen kann. Er kann insbesondere extrem groBen Aufwand bei e i n z e l n e n Sprachk o n s t r u k t i o n e n an besonders hohen Werten der entsprechenden R e d u k t i o n s z ~ h l e r erkennen.
128
1.3.3 Neben der Anzahl der Kontexte zu einer k r i t i s c h e n Produktion geben die Kontextl~ngen Hinweise auf den Analyseaufwand. Der Sprachentwerfer erh~It Angaben zur Kontextabh~ngigkeit einzelner syntaktischer Konstruktionen, die er in didaktischer Hinsicht als Frage nach der Erlernbarkeit der Sprache i n t e r pretieren kann. Und zwar i s t der Lernaufwand umso gr~Ber, je kontextabh~ngiger
die Sprachkonstruktionen
sind. Zu lange
Kontextbedingungen wie auch zu v i e l e verschiedene Kontextbedingungen r e c h t f e r t i g e n aus didaktischen GrUnden, den Entwurf abzulehnen. (ALGOL60 hat Kontextl~ngen yon etwa 1-2 syntaktischen Zeichen rechts und/oder l i n k s . )
1 . 3 . 4 Wird in den F ~ l l e n so g i b t
3) und 4) die Kontextsuche abgebrochen,
es neben den g e k l ~ r t e n
ein-
und mehrdeutigen Regeln
k r i t i s c h e Regeln. Ein P r o d u k t i o n s s y s t e m mit k r i t i s c h e n Regeln i s t zwar v o l l s t ~ n d i g ( f a l l s keine M b g l i c h k e i t e n nach i) oder 2) e l i m i n i e r t w u r d e n ) , abet es i s t Programmiersprache
fraglich,
tauglich
ob der u n t e r s u c h t e Entwurf e i n e r
ist~
Vorhandene M e h r d e u t i g k e i t e n sind zu u n t e r s u c h e n , ob s i e auf andere A r t , z~B. durch semantische Regeln, e l i m i n i e r b a r s i n d .
1.4 B e i s p i e l Als B e i s p i e l
werde die T e i l g r a m m a t i k
fur
arithmetische
Aus-
drUcke aus ALGOL60 g e w ~ h l t : T::= F
I T
x
F
F::=V
I(
S )
S::= T
I S +
T
E: := S
Auf d i e s e Ausgangsgrammatik
bezogen l a u t e t
das E r g e b n i s :
129
[+]
T ::= F
[(]
T:::F
[.]
T
::F
T
::=
T x F
F
::=
V
F::=(S)
[(]
s::=T
[I]
[(1 [~]
~ := T s::= T
[+1
[+]
[~]
s::=
~
[.]
s ::=s+
TIll
s ::oS+T[+] s ::= s ÷ T F ~ ]
E:::
s
[.1
2. Der erzeugte Parser Der Parser b e s t e h t aus einem f e s t e n und einem v a r i a b l e n T e i ! : Der f e s t e T e i l Teil
beschreibt die Analysevorschrift,
der v a r i a b l e
e n t h ~ I t das vom P a r s e r - G e n e r a t o r erzeugte P r o d u k t i o n e n -
system. Das erzeugte kontextabh~ngige Produktionensystem l ~ B t sich auf v e r s c h i e d e n e Arten l e s e n .
Dadurch kann der Parser in der A r t ,
wie er d i e Kontextbedingungen abzuprUfen h a t ,
b e e i n f l u B t werden.
Nach der b i s h e r i g e n A n a l y s e s t r a t e g i e wird eine Z e i c h e n r e i h e daraufhin geprUft,
ob die R e l a t i o n
benachbarte Alphabetelemente g i l t , Stellen,
an denen ein R e d u k t i o n s s c h r i t t
Reduktionen a u s g e f U h r t . "Lauf" ist.
~ fur je
x9
m6glich i s t ,
Das Ergebnis wird
genauso w e i t e r b e a r b e i t e t ,
Eine m o d i f i z i e r t e
zwei u n m i t t e l b a r
und es werden an a l l e n diese
in einem w e i t e r e n
bis es auf ein Axiom r e d u z i e r t
Strategie ist
nun, d i e Zeichen der
l i n k e n S e i t e a l s n~chste zu v e r a r b e i t e n d e Alphabetelemente anzusehen. Dieses V e r f a h r e n ~ h n e l t dem K e l l e r p r i n z i p . diese S t r a t e g i e werden "L~ufe" e i n e r angewendeten P r o d u k t i o n
gespart.
Durch
+
/
/x
x
x
+
x
+
+
x
f I/~'u~ S +.+.+ ~~ ' ' ' ' l / - ' " ''n
+
+
x
+
d+
~..
I N +
I
I
~
/
#
I
+
.~
l
#+
/~
#
+
/~
J+
+
,z__~
/
~
i
+
+
~
~.
+
N+
I
~
s
j+
v
+
X
+
::= <empty> ~=
{, ~0to, <designational expression>, <empty>, <procedure statement>, ,
:, }.
Dadurch ist die Klasse aller Struktureinheiten zu festgelegt.
156
,I[
~
3
3 .........
Figur 2 Der Untergrammatik M
: {x I x 6
%{ zugeordnetes
~
A
Syntaxgebilde
17 _< x _< 28};
t : 17
I
Einige
1.
1
Anmerkungen
und Folgerungen:
Verb
(Pl 14)
+ N
Feld
(pll2ag)\Vorb
f (p
t~)
4 T
I
2. f
(t) I
3. Wenn
: S.
I
(m, [ ) e p4, dann ist f 1
4. Die Elemente
(m) : f 1
aus Naohb
(m). 1
(p 123)\ Verb
(pl), nach Axiom
1
eine Obermenge mente',
yon Verb
(p4) werden 'relativ-terminale Ele1 1 aus Verb ( p ) \ Nachb (p123)'relativ1 1 genannt. Daraus geht hervor, dab ein
die Elemente
initiale
Elemente'
E 1 e m e n t
nicht
tial sein kann.
Dagegen
Z e i e h e n , terminalen Zeiehen, initialen 5. Jedes
(S4b)
1
zugleich
relativterminal
istlnach 3.
das ist der Funktionswert
Element,
gleich
dem zugeh~rigen
das ist der Funktionswert
und relativini-
ein relativterminales in einem relativrelativinitialen
im zugehSrigen
relativ-
Element.
zu g e g e b e n e m ~ e i n e
Teilgebilde
eines
Untergrammatik
Syntaxgebildes
repr~sentierende
ist ein Syntaxgebilde.
157
6. Wird die gesamte ALGOL 60-Grammatik
durch ein Syntaxgebilde l
repr~sentiert,
so liegen in dem Beispiel
22, 25 und 27 yon M
im Vorbereich,
die Elemente
das Element
~9, 21,
17 im Nachbe-
1 reich der Relation
p4. Damit wird noch einmal auf die bereits 1
erw~hnte Bedeutung
der Relation
p4 verwiesen:
Sie bestimmt
die
1
Verbindung
zwischen den Teilgebilden,
Klassen von Struktureinheiten
die Untergrammatiken
repr~sentieren.
dargestellte
Syntaxgebilde
tureinheiten
mit relativinitialem Zeichen
Beim Durehlaufen
eines Syntaxgebildes
der die alternativen Strukturbaum
~
repr~sentiert
M~glichkeiten
bzw.
Das in Figur 2
die Klasse aller Struk.
erh~it man unter Ber~eksichtigung
bestimmenden
Relation
und als dessen Terminalzeiehenreihe
aus L. T baut sich aus den beim Durchlaufen
p3 einen I ein Programm
der Wurzelb~ume
anfallen-
den Struktureinheiten
auf. Damit ist auf der Seite der Syntax der Be-
griff Struktureinheit
formal erfaSt.
3.3. Das Semantiksebild e Es ist nun noeh notwendig, Form einer Obersetzung gender
~bersetzten
jeder Struktureinheit
der Struktureinheit
Struktureinheiten
in einer bedeutungstragenden deutung
b(~) definiert
Das Semantikgebilde
O ~-(M, 2
f
2
012, P22, p3
,
p
in
und das Zusammenf~-
zu erm~gliehen.
Damit kann dann
zu einem Element
~ 6 L seine Be-
werden.
a 2 ist ebenfalls
2
: Feld
Sprache
eine Bedeutung
zuzuordnen
4 , T~2 ,
t
2
ein ~ - G e b i l d e :
) 2
(~123~) + A~ ist eine totale Funktion.
2
2
Die Begriffe
2
'relativinitial'
aueh in Semantikgebilden Ein Semantikgebilde,
und
'relativterminal'
werden entsprechend
benutzt.
das als eine Obersetzung
des Syntaxgebildes I
angesehen wird,
soll ein zu ~
korrespondierendes Semantikgebilde i ( a ) gekennzeichnet werden.
genannt werden und durch ~ 2
Def.
i
2 Ein zu ¢
korrespondierendes Semantikgebilde ~ ( ~ ) kurz I 2 i Semantikgebilde zu ~ - ist entweder ein isomorphes Bild yon I unter h : M + M mit h ( t ) = t oder ein Gebilde, das aus I
I
2
1
einem zu ~ k o r r e s p o n d i e r e n d e n tare Transformation
2
Semantikgebilde
hervorgeht.
durch eine elemen-
158
Elementare Transformationen mantikgebilde ~
(~) 2
:{
an dem zu ~ (M , pl 2
I
IP3' P~
, 02
2
korrespondierenden
2
2
f2 ,
,
t
2
)
Se-
:
2
(I) Voraussetzung:
V m 4 : (m , m ) ~ pz A m ¢ Vorb (p1~). 1 2 2 Transformation: 'Entferne m aus 6" ( ~ ) ' 2 1 : ~ p2 := p2 \ {(m , m)}. 2 2 1 Wenn ~/m2 : (m~ m 2) E P22, (p~\{(m,
dann p22 := (~) Voraussetzung:
Vm
eNachb
(p t 2 3 ) /~ m ~ M 2
1
Transformation:
m2)})U{(m~,
'F~ge m nach m : ~ Wenn
Vm
2
(3) Voraussetzung:
2
in ~
( ~ ) ein' 1 2 ! : (m , m )& p2 1
2
:= 02 U{(m{,m 2
2
1'
2
2
Feld ( p l Z 3 g ) .
2
dann p2 := ( p ~ \ { ( m ~2
~
m2)}) U { ( m
(m, n).
Sei (m, m )e p2 und (m , n ) ~ 2
, m~}.
)}.
V m, n e Feld (P22)AVK22
Transformation:
m~)}.
2
3
2
P2"
'Vertausche m und n in ~ { ~ )' 2 i :4 Wenn V m dann
O2 2
4
:
;=
(n,
m ) e p2 4 2
(p2 \{(n, 2
m )})
4
U {(m,
m )}.
4
P22 :: (p22 \{(m, m2) , (m3, n)})"
u{(n, m 2 ), (m3 ' m)}. {
F~r i
::
1,
2,
3:
Wenn Vm
1
:
(m , m) e p 1
dann p2t :: (p2{ \{(ml, Wenn V m
5
:
(m,
2
,
m)})u{(ml,
n)}.
m ) ep a 5 2~
dann 0 3 :: {p 3 \{(m, m )})I]{(n, m )}. 2
2
5
5
159
Wegen der Zul~ssigkeit
der Vertauschungstransformation
die relativterminalen,
nichtterminalen
Elemente,
ist es notwendig,
d.h. die E!emente aus
dem Vorb
(p~) und Vorb (p4) einander explizit zuzuordnen. i 2 durch die 'Assoziationsrelation' pl : ~ { ( x , y) I x g V o r b 12
Das geschieht (p4)^y = h (x)}. l
Durch diese Zuordnung von ~
und @ ( @ ) erh~it nicht nur jedes eine 1 2 1 Klasse yon Struktureinheiten repr~sentierende Teilgebilde (d.h. jeder Wurzelbaum) tureinheit
von 6 eine Obersetzung zugeordnet, sondern auch jede Struk1 und damit die zugehSrigen terminalen bzw. relativterminalen
Zeichenreihen.
Denn das Durchlaufen
eines Semantikgebildes
durch das Durchlaufen des Syntaxgebildes
6
1
zu g i s t 1
eindeutig bestimmt.
4: BeisPiel Zur Veranschaulichung von A h o u n d
Ullman
der eingef~hrten
[I] angegebenen
Begriffe
Beispiel einer ~bersetzung
schreibung mit Hilfe eines Ubersetzungsschemas Hilfe von Syntax- und Semantikgebilde a) ~bersetzungsschema
~:~
soll in einem einfachen der Be-
~-die Beschreibung mit
gegen~ber gestellt werden.
({S}, {a, +}, {a, +}, {as +}, R, S).
(i)
R : ~ { S ÷ + S ~l) S (z) , S d ) + S(zl; S ÷ a, a}. In der folgenden aus ~ abgeleiteten nichtterminale
0bersetzung werden assoziierte
Zeichen dutch den gleichen Index gekennzeichnet.
Da-
dutch m~ssen jeweils vor Anwendung der ersten Rege! die Indizes ge~ndert werden. Beispiel einer Ableitung: (S, S) -9 (+ S ~n
S (2) , S(I)
+ S(2) )
--~ (++ S (3) S C~) S(2), S {~) + S (4) + S(2) ) --9 (++ aS (~) S (2) ~ a + S (W
+ S(2) )
--~ (++ aaS, a + a + S) (++ aaa, a + a + a).
b) Be± Verwendung von Syntax- und Semantikgebilden
kann jedes in dem Ge-
bilde als Funktionswert yon fl auftretende Zeichen als Individuum identifiziert werden. Die Assoziationsrelation pl besteht aus den 12 Paaren assoziierter Elemente aus Vorb (p~) bzw. Vorb (p4) und erf~llt dieselbe Aufgabe wie die wechselnden leitungsschemas.
1
2
Indizes in den Regeln des Ab-
160
/I //
//'/I
Ill++"
"
4/
/ I
~
i / ~i/ 4/
3
3
............
k
J
\
7
Figur 3a Syntaxgebilde zu (I): t
: I
v2Js
I
Figur 3b Semantikgebilde zu (I); t : 10
1
Die Assoziationsrelation
4Z
5
2
ist pl = {(3, 12), (4, 14)}. 12
~. ~
Figur 4a Strukturbaum ~ zu (2)
5
Figur 4b Obersetzung des Strukturbaums
Mit Hilfe des Strukturbaums ~ und seiner Obersetzung wird die Terminalzeichenreihe ~ = + + a a a yon ~ in a + a + a, die Bedeutung b (~) yon ~, ~bersetzt.
161
Schlu~bemerkunsen Die EinfHhrung
der Begriffe
Syntaxgebilde
erster Schritt auf dem Weg, die gesamte grammiersprache
mit Hilfe yon Relationengebilden
sind jedoch weitere
Relationengebilde
turen zur Identifizierung Daten' bzw.
und Semantikgebilde darzustellen.
erforderlich,
deklarierter
zum 'Zugriff auf Daten'
ist ein
Syntax und Semantik einer Pro-
GraVen und zur
dienen.
Dazu
die als Hilfsstruk'Speicherung
Die Bedeutung
yon
eines aus
einem Syntaxgebilde ~ abgeleiteten Programms ist dann durch die, siI multan mit diesem P r o g r a ~ in dem zu ~ gehSrigen Semantikgebilde I
(a) 2
abgeleitete,
terminale
Zeichenreihe
bestimmt.
Jedes
'Zeichen'
I
dieser Reihe ist ein Element
aus A~ und stellt eine Folge elementarer 2
Befehle
dar.
Wesentliche
Bestandteile
sind Operationen
der hierbei bendtzten
an Relationengebilden. recht umfangreich
Die in der Existenz mende ~hnlichkeit mationen, se Gebilde
in Kauf nehmen,
von Syntax- und Semantikgebilde
Durch die Definition
z.B. verkleinert
daraus eine M~glichkeit, Zwecke merklich
zum Ausdruck
kom-
von Syntax und Semantik legt aber
die simultan an beiden Gebilden ver~ndert
da5 die
werden.
der Beschreibung
noch einen anderen Gedanken nahe:
Sprache
Die Sprache kann dadurch sehr
einfach sein; man mu~ aber m6glicherweise Hilfsstrukturen
semantischen
von Transfor-
auszufHhren
werden.
sind, k~nnen die-
Vielleicht
die gesamte Sprachbeschreibung
ergibt
sich
f0r bestimmte
zu vereinfachen.
Literatur [I] Aho, V.H., Ullman J.D.: compiling. [2] Naur, P.
Vol.
The theory of parsing, translation,
I. Englewood
Cliffs
(N.J.):
Prentice-Hall
(ed.): Revised report on the algorithmic
ALGOL 60. Numer.
and 1972.
language
Math. ~, 420 - 453 (1963).
Dr. Wolfgang Niegel Mathematisches Institut Technischen Universit~t 8ooo M~nchen 2 Arcisstr.
21
der M~nchen
ALSl - EINE HUHEREPROGRAMMIERSPRACHE ZUR TRANSFORMATIONVON ALGOL 68-VERBUNDENIN SIMULA-KLASSEN U. KASTENS
1. Ei.nf.Uhrun~ Die vergleichende Betrachtung von ALGOL 68 und SlMULA zeigt, dab diese Programmiersprachen in einigen grundlegenden Sprachelementen wie den Datenstrukturen verwandte Eigenschaften haben. Es l i e g t daher nahe, die M~glichkeiten der Transformation zwischen diesen Sprachen zu untersuchen. Das Resultat solcher BemUhungen i s t die Definition der h~heren Programmiersprache ALSl (ALGOL 68, SI__MULA)ZKa73], die einen gro~en Teil von ALGOL 68 mit dem Verbundkonzept als Kern enth~It und die Bedingung der Obersetzbarkeit in SIMULA e r f U l l t . Im Folgenden sollen zun~chst ALGOL 68-und SIMULA-Datenstrukturen vergleichend gegenUbergestellt werden. Dabei beziehe ich mich noch auf die ursprUngliche Definition von ALGOL 68 in [Wi69] nicht auf die 1973 revidierte Fassung.
2. GegenUberstellung der Datenstrukturen Die Definition der elementaren Datenobjekte stimmt in beiden Programmiersprachen nahezu Uberein. Das Konzept der zusammengesetzten Objekte i s t in ALGOL 68 "orthogonal" in die Ubrigen Spracheigenschaften i n t e g r i e r t , w~hrend bei SIMULA das Klassenkonzept historisch aus den Problemen der Simulation diskreter Systeme entwickelt und auf ALGOL 60 aufgepflanzt wurdeo In ALGOL 68 werden Objekte nachihrer "Art" (mode) unterschieden, die im Wesentlichen f e s t l e g t , welche Operationen auf ihnen ausfUhrbar sind. Wir wenden im Folgenden diese Terminologie auch auf SIMULA an.
2.1Verbunde Unter Verbunden verstehen wir zusammengesetzte Objekte, auf deren Komponenten direkt durch Angabe einer Komponentenbezeichnung zugegriffen werden kann. In ALGOL 68 unter-
163
l i e g t die Art der Komponenten keinen speziellen Einschr~nkungen, mit der Ausnahme, dab ein Verbundobjekt kein Objekt von gleicher Art enthalten kann. Die Art eines Verbundobjektes wird bestimmt
durch die Komponentenarten und -bezeichnungen und die Anzahl
und Reihenfolge der Komponenten. Das folgende ProgrammstUck zeigt die Vereinbarung eines Verbundobjekts und Zuweisungen an dessen Komponenten struct (real radius, struct (real x,y) mittelpunkt) k:= (1,(0,0)); radius of k : : 1.5; mittelpunkt o f k:= (1.0, 2.0)
In ALGOL 68 kann durch Artvereinbarung fur Verbundarten (wie auch fur andere Arten) eine Bezeichnung eingefUhrt werden. Die Vereinbarungen struct kreis = (real radius, punkt mittelpunkt); struct punkt = (real x,y); kreis k:=(1,(O,O)) haben zusammen die gleiche Bedeutung wie die Vereinbarung im obigen Beispiel. Diese Artbezeichnungen sind nur als Kurzschreibweise fur die vollst~ndige Artangabe zu verstehen; siesindkein unterscheidendes Merkmal der Art. Es i s t deshalb m~glich, dab Arten, die verschieden angegeben werden, gleich sind: struct ml = (real k, ref m2 e) struct m2 = (real k, ref ml e) Der Obersetzer muB solche, und auch komplexere F~lle erkennen (Artidentifizierungsalgorithmen von Koster [Ko69] und Zosel [Zo71]). Zusammengesetzte Objekte werden extern durch Angabe einer Liste der Komponenten notiert. Da weder die Art noch Komponentenbezeichnungen in dieser Notation angegeben werden, i s t es Aufgabe des Obersetzers, aus dem Kontext zu ermitteln, von welcher Art das Objekt i s t . In SlMULA i s t die Wiedergabe von ALGOL 68-Verbunden m~glich durch entsprechende Spezialisierung des m~chtigeren Klassenkonzeptes. Das oben betrachtete ProgrammstUck kann etwa so formuliert werden:
class kreis (radius, mittelpunkt); real radius; re_f_f(punkt) mittelpunkt;; class punkt (x,y); real x , y ; ; ref (kreis) k; k:-new kreis(1, ne___ww punkt (0,0)); k.radius::l.5; k.mittelpunkt.x:=l.O; k.mittelpunkt.y:=2.0; Enth~It ein Verbund einen anderen Verbund als Komponente, so i s t das in SIMULA durch einen entsprechenden Verweis auszudrUcken. Dabei wird ausgenutzt, dab das "r~umliche Enthalten" und das "Verweisen" gleichwertige Implementierungen desselben Prinzips sind. AuBer dem Generierungsoperator gibt es in SIMULA keine Operation, die ein Klassen-Objekt als Einheit behandelt. Das Zuweisen von Verbundwerten erfolgt deshalb komponentenweise. Da die explizite Vereinbarung yon Klassen mit Zuordnung einer Klassenbezeichnung vorgeschrieben ist, existiert das Problem der Artidentifikation hier nicht.
Die Anwendungsm~glichkeiten von Klassen gehen Uber die Realisierung von Verbundobjekten hinaus, denn innerhalb einer Klassenvereinbarung k~nnen Anweisungen angegeben und Prozeduren vereinbart werden, die dann selbst Verbundkomponenten sind. Mit diesen Hilfsmitteln kann z.B. eine einfache Kellerorganisation folgendermaBen implementiert werden: class keller (laenge); integer laenge; be~inar_.r.~.~ a (l:laenge); "int.e~er pegel; boolean v o l l , leer; real procedure pop; begin pop:=a(pegel); pegel:=pegel-1; leer:=pegel=O end; procedure push (x); real x; begin pegel:=pegel+l; a (pegel):=x; voll:=pegel=laenge end.; pegel:=O; voll:=false; leer:=true
end Ein solches Objekt wird z.B. durch die Anweisung s:-new keller (100)
165
generiert. Zugriffe auf Elemente dieses Kellerobjektes k~nnen dann z.B. so formuliert werden i_f no___tts.voll then s.push (3.4) oder
i f not s.leer then y::s.pop
Die Methode, mit der der Keller imp]ementiert wurde, braucht auBerhalb der Klassenvereinbarung nicht zur Kenntnis genommen zu werden - es h~tte ebenso gut eine lineare Liste statt einer Reihung verwendet werden k~nnen (vergleiche Parnas [Pa72]). Nach dem gleichen Prinzip werden in SIMULA die Standardklassen SIMULATION und SIMSET d e f i n i e r t , die Datenstrukturen und Operationen zur Simulation bzw. Listenverarbeitung bereitstellen. Anwendungen dieser Art legen es nahe, eine Klassenvereinbarung aufzufassen als die Def i n i t i o n einer Datenstruktur zusammen mit den auf ihr ausfUhrbaren Operationen in geschlossener Form. In ALGOL 68 i s t ein analoges Konzept nicht vorhanden. Der Aufbau einer ~hnlichen Konstruktion macht dort erhebliche formulierungstechnische Schwierigkeiten. Verbunde k~nnen zwar Prozedurvariablen als Komponenten enthalten; die Prozeduren mUssen abet jeweils bei der Generierung eines solchen Verbundes von auBen zugewiesen werden. Im letzten Beispiel haben wir den Anweisungsteil der Klassenvereinbarung nur zur Initialisierung der Komponenten verwendet. Durch geeigneten Aufbau des Anweisungsteiles kann eine Klasse eine oder mehrere gleichartige Koroutinen definieren; z.B. das f o l gende vereinfachte Produzent-Konsument-System: class produzent be~in i n i t i a l i s i e r e
class konsument ;
begin i n i t i a l i s i e r e ;
detach; while bedingung do
detach; while bedingung do
begin produziere; resume (k)
begin verbrauche; resume (p)
end end
end end
Eine weitere Anwedungsm~glichkeit von SIMULA-Klassen l i e g t in der Erzeugung p a r t i e l l parametrisierter Prozeduren. Die im folgenden Beispiel definierte Klasse erzeugt abh~ngig von den Parametern entsprechende Polynomfunktionen, die z.B. in einer Integrationsprozedur ausgewertet werden:
166
class polynom (grad, koeffizieten); integer grad; ar__EZ~ "ykoeffizienten; begin real procedure polynomwert (x); value x; real x; begin real s; integer i ; s:=koeffizienten (grad); for i:=grad-lst_s_t#_E-1 until 0 do s:=s*x+koeffizienten ( i ) ; polynomwert:=s end end Ein Aufruf der Integrationsprozedur k~nnte dann z.B. lauten integral (new polynom (5, koeff ).polynomwert, 0.5, 2.1) Derartige Konstruktionen sind in SIMULAm~glich, da alle Objekte unbeschr~nkte Lebensdauer haben, w~hrend in ALGOL 68 als Kellersprache solche partiell parameterisierbaren Prozeduren nicht formuliert werden k~nnen.
2.2 VereinigungsarteE FUr eine Reihe von Anwendungen ist es erforderlich, Variable
zu haben, die Objekte
von unterschiedlicher Art als Inhalte besitzen k~nnen. In ALGOL68 wird die Art einer solchen Variablen ausgedrUckt als ein Bezug auf die Vereinigung der Arten, die die m~glichen Werte annehmen k~nnen, z.B. ref union (real, int, ref formel) In der ursprUnglichen Definition von ALGOL68 sind die Uber den einzelnen Arten definierten Operatoren nicht auf Objekte der union-Art anwendbar, vielmehr muB man erst mit einer speziellen Zuweisung("conformity relation") das Objekt an eine Variable der betreffenden Teilart zuweisen. In SIMULAwird die Vereinigung verschiedener Arten auf Klassen beschr~nkt. Mit Hilfe yon Pr~fixen in den Klassenvereinbarungen k~nnen Hierarchien yon Klassen definiert werden. Wollen wir z.B. eine Listenstruktur aufbauen aus Elementen, die unterschiedliche Komponenten haben wie die Klassen class listeleml (nachf, k); ref (listelem) nachf; integer k;; class listelem2 (nachf, c); ref (listelem) nachf; character c; so k~nnen wir die beiden Klassen zu einer "Oberklasse" zusammenfassen:
167
class l i s t e l e m (nachf); r e f ( l i s t e l e m ) nachf;;
listelem
class l i s t e l e m l ( k ) ; inte~..er k ; ;
listelem
class l i s t e l e m 2 ( c ) ; character c ; ;
Die in beiden Unterklassen gleiche Komponente (nachf) kann in der Oberklasse d e f i n i e r t werden. Der Z u g r i f f auf Komponenten, die in der Unterklasse d e f i n i e r t sind e r f o r d e r t , dab entweder die Klassenbezeichnung als"Qualifikation"angegeben oder das Objekt - wie in ALGOL 68 - an eine geeignete Variable zugewiesen wird. 1 qua l i s t e l e m l , k oder
11:-I; ll.k
Nach dem gleichen Schema i s t eine Hierarchie yon Standard-Klassen zur Organisation der Ein- und Ausgabe definiert. Jedem Datei-Typ i s t eine Klasse zugeordnet, die die j e w e i l i g e n Bearbeitungsprozeduren als Komponenten e n t h ~ l t : class f i l e file
...
class d i r e c t f i l e
f i l e class i n f i l e
...
...
f i le class o u t f i l e . . . o u t f i le class p r i n t f i l e
...
o u t f i le class punchfile . . . Die Artvereinigung aus ALGOL 68 kann in SIMULA durch die D e f i n i t i o n einer Oberklasse ohne Komponenten d a r g e s t e l l t werden: union m : (m~l, m2) e n t s p r i c h t den Klassenvereinbarungen class m;; m class ml . . . . m class m2. . . .
2.3
Reihungen
In SIMULA wurde das Array-Konzept unver~ndert aus ALGOL 60 Ubernommen. ALGOL 68Reihungen weichen davon vor allem nur in den folgenden Punkten ab: - Der Deskriptor einer Reihung i s t auf der Programmebene insoweiz zug~nglich, dab die Indexgrenzen abgefragt und im Falle yon flexiblen Grenzen auch ver~ndert werden k~nnen. Durch Erzeugen eines ver~nderten Deskriptors k~nnen die Indexgrenzen "getrimmt" bzw. Reihungsausschnitte definiert werden. Operationen mit Reihungen als Einheiten, insbesondere Zuweisungen sind m~glich.
168
-
Reihungen k~nnen e x p l i z i t als Folgen von Elementen angegeben werden, z.B. [1:4] i n t a = (1,2,3,4) [1:2, 1:3] i n t b : ( ( 1 , 2 , 3 ) , ( 4 , 5 , 6 ) )
2.4 Namen In der Algol 68-Terminologie werden unter "Namen" Verweise auf Bezugsobjekte im Sinne von Variablenadressen verstanden. Das Namenskonzept basiert auf einer strengen Hierarchie: Mit der Referenzstufe eines Namens i s t die Anzahl der indirekten Adressierungss c h r i t t e festgelegt, die n~tig i s t um ein Bezugsobjekt zu erreichen, das kein Name i s t . Die Referenzstufe eines Namens und die Art des Bezugsobjektes bestimmen die Art des Namens. Allen Objekten - auch Namen und Konstanten - k~nnen durch Vereinbarungen Bezeichnungen zugeordnet werden. Namen von Komponenten s t r u k t u r i e r t e r Objekte sind ebenfalls durch Bezeichnungen i d e n t i f L zierbar, z.B.: r e f i nt i = k of v r e f i n t j = a [4] Die M~glichkeit, Namen zu definieren, die auf Namen verweisen, w i r f t das Problem der "Verschleppung" von Namen auf, deren Bezugsobjekte nicht mehr e x i s t i e r e n . Das folgende ProgrammstUck i s t ein einfaches Beispiel dafUr: ref r e f i n t i i
= ref int;
be_be_~_inr e f i n t k = i n t : = 5 ; ii
:=k
en_d_d; print ( ii ) In der Zuweisung i i : = k wird der k zugeordnete Name an i i zugewiesen, dessen GUltigkeitsbereich den von k umfa~t. Um das Kellerprinzip aufrecht zu erhalten, mu~ ein Z u g r i f f auf das nic~t mehr existierende Objekt (in p r i n t ( i i ) )
verhindert werden. Hierzu w~ren
i n e f f i z i e n t e LaufzeitprUfungen n~tig; es wird deshalb die st~rkere Forderung g e s t e l l t : Der Name eines Objekts darf nicht an einen Namen zugewiesen werden, der eine gr~6ere Lebensdauer hat, als das Objekt selbst. In SlMULA i s t kein so strenges Referenzstufen-Konzept d e f i n i e r t wie in ALGOL 68. FUr Klassenobjekte existieren Namen der Referenzstufe I u n d Variable dafUr. Bei Objekten
169
einfacher Art wurde das Variablen-Prinzip aus ALGOL 60 Ubernommen. Wegen dieser unterschiedlichen Definition i s t es erforderlich, bei der Transformation alle Objekte durch Klassen zu implementieren, um einheitliche Referenzstufen darzustellen. Das Problem der Verschleppung von Namen e x i s t i e r t in SIMULA nicht, da alle Objekte unbegrenzte Lebensdauer haben. Der Vergleich auf Identit~t i s t in ALGOL 68 und SIMULA die einzig m~gliche Operation mit Namen als Operanden.
3. Transformation der Datenstrukturen Bei der Transformation von ALGOL 68-Datenstrukturen in SIMULA-Klassen i s t die Realisierung des Referenzstufenkonzeptes, der Identifizierung von Namen und der Artanpassungsoperationen die wichtigste Aufgabeo Die Ubrigen Zuordnungen k~nnen im allgemeinen durch Textsubstitution vorgenommen werden. Die Darstellung beliebig langer Verweisketten durch Referenzvariable bereitet keine prinzipiellen Schwierigkeiten, da sie aus mehreren Verweisen kettenartig zusammengesetzt werden k~nnen. Objekte der Referenzstufen 0 und 1 k~nnen durch gleichartige Klassenobjekte r e a l i s i e r t werden, lhre externe Identifizierung erfolgt durch eine Referenzvariable. Benannte Objekte der Referenzstufe 0 werden dann als schreibgeschUtzte Variable aufgefa~t. Diese Unterscheidung kann vom Obersetzer vorgenommen werden. Auf gleiche Weise i s t das Problem zu l~sen, da# in SIMULA Verbundkomponenten nicht wiederum Verbundkonstante sein k~nnen: Es wird stattdessen eine Referenzvariable als Komponente angegeben, deren Wert ein unver~nderlicher Verweis auf ein entsprechendes Objekt ist. Objekte der Referenzstufe 2 werden dargestellt durch Klassenobjekte, die als einzige Komponente eine Referenzvariable vonder entsprechenden Art besitzen. Damit ergibt sich das folgende Abbildungsschema: Sei m eine beliebige Art. So entsprechen der ALGOL 68-Artvereinbarung mode vb = struct (~ ko, ref m kl, ref ref m k2) die Klassenvereinbarungen class vb; be~in ref (m) ko; ref (ref m) kl; ref (ref m) k2; >Zuweisungsprozedur< end
>Initialisierung
