Programmiersprachen und ihre Übersetzer. Syntaxorientierte Übersetzung

Transkript

1 Folien zur Vorlesung Programmiersprachen und ihre Übersetzer Kapitel 3 Syntaxorientierte Übersetzung Faculty of Technology robert@techfak.uni-bielefeld.de May 27, 2013

2 Aufbau von Programmiersprachen Programmiersprachen bestehen aus einer relativ kleinen Anzahl von Konzepten. Solche Konzepte sind etwa Typ- oder Klassendefinitionen, Typdeklarationen, Funktionsdefinitionen (sei es durch Gleichungen oder durch Anweisungen mit Kontrollstruktur), Audrücke, spezielle Notationen für vordefinierte Datentypen, Angaben zur Programmstruktur (Module, Pakete). Jedes dieser Konzepte hat seine Semantik. Eine Sprache ist um so einfacher zu lernen, zu verstehen und zu nutzen, je weniger Konzepte sie braucht, und je freier diese kombiniert werden können (und dabei immer noch verständlich bleiben). Das nennt man auch Orthogonalität.

3 Abstrakte und konkrete Syntax Konkrete Programme entstehen durch Kombination dieser Konzepte, und diese Kombination ist immer rekursiv. Diesen Aufbau nennt man die abstrakte Syntax des Programms. Die lineare Zeichenkette, die wir als Programmtext eingeben, nennt man konkrete Syntax. Sie verschleiert oft diesen rekursiven Aufbau eher als dass sie ihn aufzeigt. Die Aufgabe der Syntaxanalyse ist es, die abstrakte Struktur in der konkreten Syntax zu erkennen.

4 Beschreibung und Vermittlung von Programmiersprachen Die Syntax von Programmiersprachen wird traditionell durch kontextfreie Grammatiken beschrieben. Nicht zu Unrecht sind kontextfreie Grammatiken deswegen eines der meistgenutzten formalen Konzepte der Informatik. Trotzdem ist diese Tradition nicht unproblematisch, und eine kleine Kritik sei erlaubt.

5 Doppelfunktion der CFG Genau betrachtet, löst die kontextfreie Grammatik zwei Aufgaben: Es wird eine konkrete lineare Notation angegeben, in der die rekursiv verschachtelten Sprachkonstrukte aufzuschreiben sind, so dass die abstrakte Syntax aus der linearen Aufschreibung (re-)konstruiert werden kann {, } oder begin, end in Anweisungen, (, ) in Ausdrücken, ; zwischen Anweisungen Zugleich wird implizit die abstrakte Syntax festgelegt: Dürfen Typdeklarationen Ausdrücke enthalten? Können Prozeduren geschachtelt definiert werden? Angaben zur Modulstruktur müssen am Anfang stehen! Einfacher wäre das Lernen von Programmiersprachen, wenn diese beiden Aspekte getrennt beschrieben wären.

6 Regeln der abstrakten Syntax Hinter der abstrakten Synax stehen Design-Entscheidungen, wichtige methodische oder semantische Erwägungen, etwa: Man will verlangen, dass Angaben zur Modulstruktur am Programmanfang auftreten, und nicht versteckt in der Mitte. Man will keine Deklaration neuer Typen innerhalb von Ausdrücken zulassen, weil dies zu unübersichtlichen Programmen führt. Man will in imperativen Sprachen keine Funktionen in Datentypen zulassen, weil man in diesen Sprachen dafür keine vernünftige Semantik angeben kann. Und so weiter.

7 Regeln der konkreten Syntax Ganz anders sind die Regelungen der konkreten Syntax - hier geht es nur um die Aufschreibung.

8 Regeln der konkreten Syntax Ganz anders sind die Regelungen der konkreten Syntax - hier geht es nur um die Aufschreibung. Was heißt da nur die konkrete Syntax ist von erheblicher praktischer und strategischer (!) Bedeutung. Wie will man die abstrakte Syntax zum Ausdruck bringen? Will man wirklich syntaktische Klammern einführen, oder verwendet man dafür das Layout (Abseitsregel)? Dabei kommt es auf Ästhetik an oder Gewohnheit. Java sucht die syntaktische Nähe zu C, auch wenn die beiden Sprachen semantisch viel verschiedener sind als sie syntaktisch aussehen. Haskell weicht aus rechtlichen Gründen von in Miranda bewährten Notationen ab...

9 Getrennte Definition?? Es wäre also generell nicht verkehrt, eine Trennung zwischen abstrakter und konkreter Syntax einer Programmiersprache explizit zu machen. Vom Standpunkt des Übersetzerbaus her braucht man sie ohnehin.

10 Getrennte Definition?? Es wäre also generell nicht verkehrt, eine Trennung zwischen abstrakter und konkreter Syntax einer Programmiersprache explizit zu machen. Vom Standpunkt des Übersetzerbaus her braucht man sie ohnehin. Übung Wie steht s damit bei Bellman s GAP?

11 (Konkreter) Syntaxbaum und (abstrakter) Programmbaum Der Ableitungsbaum der CFG ist der konkrete Syntaxbaum, und ist viel komplizierter als man für die Übersetzung braucht. Für die Übersetzung wird die abstrakt Syntax gebraucht, d.h. der Programmbaum, der eine Abstraktion des konkreten Syntaxbaums ist.

12 Ein Beispiel zur konkreten und abstrakten Syntax Einfache arithmetische Ausdrücke können repräsentiert werden durch den Datentyp Expression: > module Ableitung where > infixr :+: > data Expression = Times Expression Expression > Plus Expression Expression > Minus Expression Expression > AsExp Identifier > type Identifier = String x * (y + z) wird zu Times (AsExp "x") (Plus (AsExp "y")(asexp "z"))

13 Abstrakter Ausdrucksbaum Als Baumstruktur sieht der Ausdruck so aus: times asexp plus x asexp asexp y z Natürlich will man Programme weder in Baumdarstellung, noch in der Präfix-Notation eingeben. Die übliche Schreibweise ist eine Zeichenreihe mit infix-operatoren, und wenn nötig Klammern.

14 CFG für Ausdrücke Kontextfreie, eindeutige Grammatik für arithmetische Ausdrücke in üblicher Notation, E E + T E E T E T T T F T F F (E) F Id Id x y z Als Syntaxbaum für x (y + z) ergibt sich

15 E T T F F ( E ) Id E + T x T F Id F Id z y

16 Zu konkret!! Der Syntaxbaum enthält sehr viel an semantisch irrelevanter Struktur, Kettenregeln E T, T F und F Id. Operatoren wie Nonterminals, wo Operatoren alleine ausreichend sind, semantisch irrelevante Terminalsymbole, wie die Klammern. Diese Details verschwinden in der abstrakten Syntax, werden uns aber in Kap. 4 wieder begegnen.

17 Übersetzungsschemata Da das Programm eine rekursive Datenstruktur ist, folgen alle Übersetzungsphasen im wesentlichen dem Schema der strukturellen Rekursion; allerdings sind, je nach Schwierigkeit des Übersetzungsschritts, ausgefeiltere Formen dieses Schemas notwendig. Drei solche Schemata werden wir kennenlernen: das einfache Ableitungsschema, das erweiterte Ableitungsschema, attributierte Grammatiken.

18 Signaturen, Terme Definition Eine Signatur Σ besteht aus einer Menge von Operationssymbolen und einer Menge von Sorten. Die Sorten sind den Operationen als Argument- und Ergebnistypen zugeordnet. Wohltypisierte Formeln aus diesen Operatoren werden Terme genannt. Mit T Σ bezeichnen wir die Menge aller Terme zur Signatur Σ, und mit T Σ (V ) diejenigen Terme zur Signatur Σ, die auch Variablen aus einer Variablenmenge V enthalten können.

19 Definition Σ-Algebren Ist Σ eine Signatur, so ist eine Σ-Algebra eine Menge von Wertemengen zusammen mit einer Menge von Funktionen, die wir als die Interpretation der Sorten und Operationen der Signatur auffassen. Für die Interpretation eines Terms t in einer Algebra A schreiben wir t A, s A für die Interpretation der Sorte s, und so weiter.

20 Definition Σ-Algebren Ist Σ eine Signatur, so ist eine Σ-Algebra eine Menge von Wertemengen zusammen mit einer Menge von Funktionen, die wir als die Interpretation der Sorten und Operationen der Signatur auffassen. Für die Interpretation eines Terms t in einer Algebra A schreiben wir t A, s A für die Interpretation der Sorte s, und so weiter. Natürlich kann jede Signatur Σ durch viele verschiedene Σ-Algebren interpretiert werden. Die einfachste Interpretation ist stets der algebraische Datentyp, der gerade zu jeder Sorte einen passenden Datentyp und zu jeder Operation der Signatur einen gleichnamigen Konstruktor angibt. Diesen Datentyp bezeichnen wir als die Termalgebra der Signatur; er ist isomorph zu T Σ.

21 Signatur für arithmetische Ausdrücke Sorten Exp 1, Id Operationen x: Id y: Id z: Id asexp: Id Exp plus: Exp Exp Exp times: Exp Exp Exp minus: Exp Exp Exp 1 Unter den Sorten wird die ausgezeichnete Programmsorte in den nachfolgenden Beispielen fettgedruckt.

22 Implementierung der Term-Algebra in Haskell Der Haskell-Datentyp Expression stellt mit der naheliegenden Zuordnung der Sorten und Operationen (Expression für Exp, Plus für plus, etc.) gerade die Termalgebra zu dieser Signatur dar; es fehlen nur die Interpretationen für die Identifier x, y, z. data Expression = Times Expression Expression Plus Expression Expression Minus Expression Expression AsExp Identifier type Identifier = String > x = "x" > y = "y" > z = "z"

23 Interpretation in der Term-Algebra Damit ist die Interpretation des Terms gerade der Haskell-Wert times(asexp(x), plus(asexp(y), asexp(z))) Times (AsExp "x")(plus (AsExp "y") (AsExp "z")). Hier passiert also nicht besonders viel. Hier sind jedoch weitere Interpretationen zur gleichen Signatur:

24 Interpretation in einer Algebra der natürlichen Zahlen Wir interpretieren die arithmetischen Ausdrücke in einer Algebra IN (Nat = Menge der natürlichen Zahlen) wie folgt: Id IN = Exp IN = Menge Nat der natürlichen Zahlen. plus IN : (n 1, n 2 ) Exp IN Exp IN n 1 + n 2 Exp IN times IN : (n 1, n 2 ) Exp IN Exp IN n 1 n 2 Exp IN asexp IN : n Id IN n Exp IN minus IN : (n 1, n 2 ) Exp IN Exp IN n 1 n 2 Exp IN x IN : 3 Id IN y IN : 17 Id IN z IN : 25 Id IN Damit ergibt sich z. B. für t = times(asexp(x), plus(asexp(y), asexp(z))) die Auswertung t IN = x IN (y IN + z IN ) = 3 ( ) = 126. Dies ist aber nicht die einzige Interpretationsmöglichkeit für arithmetische Ausdrücke.

25 Interpretation in einer Boole schen Algebra Genauso erlaubt (und auch praktisch sinnvoll) ist eine Interpretation innerhalb der Booleschen Algebra Bool: Id B = Exp B = Bool = {T, F } plus B : (b 1, b 2 ) b 1 b 2 times B : (b 1, b 2 ) b 1 b 2 minus B : (b 1, b 2 ) b 1 b 2 asexp B : b b x B : = T y B : = F z B : = T Dann ergibt sich für denselben Term t die Auswertung t B = T (F T ) = T.

26 Interpretation in der Notations-Algebra Wir kommen nun auf die Frage zurück, wie Programme als Zeichenreihen darstellbar sind: Wir interpretieren die Signatur in der String-Algebra; jeder Sorte der Signatur wird durch Strings interpretiert, und jeder Term durch seine Darstellung als Zeichenreihe. Id String = Exp String = String > t = times (asexp x) (plus (asexp y) (asexp z)) > plus a b = "(" ++ a ++ " + " ++ b ++ ")" > times a b = a ++ " * " ++ b > minus a b = "(" ++ a ++ " - " ++ b ++ ")" > asexp a = a > x = "x" > y = "y" > z = "z"

27 Notations-Interpretation In der Notations-Algebra ergibt sich für denselben Term t die Auswertung "x * (y + z)" Diese Notation ist aber noch nicht so flexibel wie man sie sich in Programmiersprachen wünscht, da manchmal unnötige Klammern gesetzt werden.

28 Notations-Interpretation In der Notations-Algebra ergibt sich für denselben Term t die Auswertung "x * (y + z)" Diese Notation ist aber noch nicht so flexibel wie man sie sich in Programmiersprachen wünscht, da manchmal unnötige Klammern gesetzt werden. Was ist dann Syntaxanalyse?

29 Interpretation in einer Algebra der Kellermaschinenprogramme Im nächsten Abschnitt werden wir als weiteres Beispiel eine Interpretation in einer Algebra von Programmen für eine einfache Kellermaschine kennenlernen.

30 Zusammenfassung (1) Wir können jetzt zusammenfassend die Begriffe Sprache, Syntax und Semantik aus Kapitel 2 präzisieren. Eine Sprache L : A (A A) wird repräsentiert durch ein Tripel (Σ, S, I), Σ Signatur, S und I Σ-Algebren. Dabei ist S die Notation der Programmiersprache, d.h. eine Interpretation von Σ in einer Algebra der Zeichenreihen. Es ist dann L-Prog = {l S l T Σ }, d.h. die Programme sind genau die Notationen der Σ-Terme der Programmsorte.

31 Zusammenfassung (2) Die Semantik L der Sprache ist gegeben als L(l) = l I, für jedes Programm l T Σ, also als das Ergebnis der Auswertung von l in I. Dabei sind natürlich nur solche I zugelassen, die der Programmsorte P eine Menge von Funktionen des Typs A A zuordnen.

32 Übersetzung durch Ableitung Da wir jetzt Programme einer Sprache L als Terme in T ΣL einer zugeordneten Signatur Σ L sehen, betrachten wir nun Übersetzer c als Abbildungen gemäß c : T ΣQ T ΣZ wenn Σ Q bzw. Σ Z die Signaturen von Quell- bzw. Zielsprache sind. Eine mögliche Form der induktiven Übersetzerdefinition wird als Übersetzung durch Ableitung bezeichnet. Der Übersetzer heißt dann Signaturmorphismus oder auch derivor.

33 Der Ableitungsbegriff Definition Eine Ableitung c : T ΣQ T ΣZ konstruiert eine Σ Q -Algebra über T ΣZ. Jeder Σ Q -Sorte s wird eine Σ Z -Sorte s c zugeordnet, jedem Σ Q -Operationssymbol f eine Funktion f c. Die Funktion f c wird dabei durch einen Term aus T ΣZ (V ) beschrieben. Einfach sind solche Ableitungen, weil sie eine rein syntaktische Transformation sind. Jeder Σ Q -Term wird durch ersetzen seiner Konstruktoren gemä s c durch einen Σ Z -Term ersetzt.

34 Notation als Ableitung Betrachten wir zum Beispiel die Interpretation von Exp in der Notations-Algebra. Die Zielsignatur (hier die Zeichenreihen) enthält unter anderem die Operation ++. Diese Operation ist selbst nicht Interpretation einer Operation aus Σ Q, wird aber benutzt, um die interpretierenden Funktionen zu definieren. Die Interpretation lautet ja gerade times N = f times mit. Also gilt z.b.. f times (a, b) = a b c(times(a, b)) = f times (c(a), c(b))

35 Notation als Ableitung Betrachten wir zum Beispiel die Interpretation von Exp in der Notations-Algebra. Die Zielsignatur (hier die Zeichenreihen) enthält unter anderem die Operation ++. Diese Operation ist selbst nicht Interpretation einer Operation aus Σ Q, wird aber benutzt, um die interpretierenden Funktionen zu definieren. Die Interpretation lautet ja gerade times N = f times mit. Also gilt z.b. f times (a, b) = a b c(times(a, b)) = f times (c(a), c(b)). Natürlich ist der Interpretationsbegriff allgemeiner als der Ableitungsbegriff, da die Funktion f times im allgemeinen auf beliebige Art definiert sein kann.

36 Notationsableitung in Haskell Ableitungen lassen sich besonders einfach funktional implementieren: > c :: Expression -> String > c (Times a b) = c a ++ " * " ++ c b > c (Plus a b) = "(" ++ c a ++ " + " ++ c b ++ ")" > c (Minus a b) = "(" ++ c a ++ " - " ++ c b ++ ")" > c (AsExp i) = c i where > c:: Identifier -> String > c i = i

37 Übersetzung arithmetischer Ausdrücke in Kellermaschinencode Wir betrachten eine einfache Kellermaschine mit drei Registern und 0-Adress-Befehlen als Ziel der Übersetzung. > data Code = ADD NEG MUL > PUSH Reg Code :+: Code deriving Show > data Reg = R1 R2 R3 deriving Show Der Befehl PUSH lädt einen Registerinhalt auf den Keller. Die Befehle ADD und MUL addieren bzw. multiplizieren auf dem Keller, NEG invertiert das Vorzeichen des obersten Kellerelementes. Weitere Instruktionen brauchen wir für unser einfaches Beispiel nicht. Der Konstruktor :+: bildet Befehlssequenzen.

38 Ausdrucks-Übersetzer Hier ist die Übersetzung e2c: > e2c :: Expression -> Code > e2c (Times a b) = e2c a :+: e2c b :+: MUL > e2c (Plus a b) = e2c a :+: e2c b :+: ADD > e2c (Minus a b) = e2c a :+: e2c b :+: NEG :+: ADD > e2c (AsExp a) = PUSH (e2c a) where > e2c:: Identifier -> Reg > e2c "x" = R1 > e2c "y" = R2 > e2c "z" = R3

39 Übersetzungsbeispiel Diese Übersetzerdefinition liefert z. B. für t1 = Times (AsExp "x") (Minus (AsExp "y") (AsExp "z")) ===> e2c(t1) = PUSH R1 :+: (PUSH R2 :+: PUSH R3 :+: NEG :+: ADD ) :+: MUL wobei die runden Klammern in c(t) bedeutungslos sind, aber noch die Struktur des Quellprogramms wiederspiegeln.

40 Die Übersetzergleichung Wir haben nun eine konkrete Repräsentation für Ziel- und Quellprogramme als Terme der jeweiligen Signatur, und eine konkrete Vorstellung von dem Übersetzer, nämlich als Ableitung. Definition Wie bisher seien Σ Q, Σ Z und c gegeben. I Q und I Z seien Σ-Algebren für Σ Q und Σ Z. c ist ein korrekter Übersetzer von der Quellsprache (Σ Q, I Q ) in die Zielsprache (Σ Z, I Z ), falls für alle t T ΣQ von der Programmsorte t IQ (c(t)) IZ gilt, d. h. falls für alle a 1 a n A a = t IQ (a 1,..., a n ) a = (c(t)) IZ (a 1,..., a n ). D.h. für alle Q-Programme ( = Terme t von Q-Programmsorte) ist die Interpretation (c(t)) IZ der Übersetzung c(t) eine E/A-Funktion, die gleich der E/A-Funktion des Quellprogrammes Robert ist Giegerich

41 Übung Man definiere für die Zielsprache (Stackmaschinencode) des Beispiels über arithmetische Ausdrücke eine Semantik, die die Intuition trifft und beweise die Korrektheit des Übersetzers.

42 Komposition von Ableitungen Interessant ist noch die Beobachtung, daß die Übersetzung durch Ableitung unter Komposition abgeschlossen ist: Für Ableitungen c 1 : Σ Q1 Σ Z1 = Σ Q2 und c 2 : Σ Q2 Σ Z2 ist c 3 = c 2 c 1 eine Ableitung von Σ Q1 nach Σ Z2. Beweis: Man wende einfach die Regeln von c 2 auf die Definition von c 1 an). Damit kann man Übersetzungen modular (eventuell über mehrere Zwischensprachen) spezifizieren.

43 Schranken des einfachen Ableitungsschemas Ableitungen sind Übersetzungsschemata, die völlig kontextunabhängig arbeiten. Probleme: 1 Viele Konstrukte in Programmiersprachen erfordern ein kontextabhängiges Übersetzen. Ein Übersetzer c, der den Kontext berücksichtigt, ist vom Typ c : Quellprogramm Symboltabelle Zielprogramm. Ableitungen c sind dagegen immer vom Typ c : Quellprogramm Zielprogramm. 2 Ableitungen können nur in einfacher Weise Operatoren der Quellsprache durch Terme in der Zielsprache ersetzen. Ein Übersetzer muss oft auch semantische Werte wirklich ausrechnen.

44 Erweiterung In realistischen Beispielen sind die durch Ableitung erzeugten Zielterme nicht die endgültigen Zielprogramme. Erst durch eine nachfolgende Auswertung (auf der leeren Eingabe) gehen sie in die tatsächlichen Zielprogramme über. Mit anderen Worten, die Terme c(t) sind zu interpretieren als Programme in einer Sprache C von Übersetzungszeitaktionen. Die Ausführung von c(t) gemäß C (zur Übersetzungszeit; auf der leeren Eingabe) liefert erst das eigentliche Zielprogramm. Solche Zweistufigkeit erhöht Modularität: Die Sprache Σ C der Compilezeitaktionen kann man für eine ganze Sprachfamilie entwerfen!

45 Ein Beispielübersetzer nach dem Ableitungsschema in Haskell Erweitertes Ableitungsschema:

46 Quell- und Zielsprache Als Quellsprache nehmen wir eine Sprache von while-programmen mit Variablendeklarationen. Als Zielsprache nehmen wir eine idealisierte Kellermaschine. Dieses umfangreiche Beispiel wurde nicht in Folien zerlegt. Siehe Skript Seite 44 51

47 Aufbau des Beispiels Abstrakte Syntax Datentypen Compiler Quellsprache Σ Q int, bool Ableitung Zielsprache Σ Z Adressen, Werte Σ Q Σ C Compileraktionen Σ C Zustand Interpretation Typprüfung Symboltabelle Zustand Σ C Σ Z Markenverwaltung 2 Zähler Dekl.Info 2 Stacks Codeausgabe Zielcode