Übung zu Grundlagen des Übersetzerbaus

Transkript

1 Übung zu Grundlagen des Übersetzerbaus Mehr zu Parsern und LL(k)-Grammatiken Lehrstuhl für Informatik 2 (Programmiersysteme)

2 Probleme bei LR-Parsern Für manche Grammatiken ist es nicht möglich, LR-Parser zu konstruieren. Beispiel: S a a S a (Sprache: ungerade Anzahl von a ) Ab 1 konsumierten Zeichen: Shift oder Reduce? Zwei mögliche Probleme: SHIFT/REDUCE-Konflikt: Soll ein SHIFT oder ein REDUCE stattfinden? REDUCE/REDUCE-Konflikt: Anhand welcher (von zwei) Regeln soll reduziert werden? Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 2 / 22

3 SHIFT/REDUCE-Konflikte Beispiel: EX ID EX + EX Input: a + b + c Nach Konsum von a + b : Stack hat EX + EX, Input ist + Frage: Soll + geshiftet werden, oder soll stattdessen a + b wegreduziert werden? Hier: Beides möglich, führt zu unterschiedlichen Parse-Bäumen Beispiel von oben: S a a S a Nur eine der zwei möglichen Entscheidungen ist richtig, die Andere führt zu einem Parse-Fehler. Welche Entscheidung richtig ist, hängt vom Input ab: Bei aaa muss nach dem 2. a reduziert werden. Bei aaaaa muss nach dem 3. a reduziert werden. Allgemein: Bei 2k + 1 a muss nach dem k + 1 ten a reduziert werden. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 3 / 22

4 Lösen von SHIFT/REDUCE-Konflikten Grammatik Ändern: Aus EX ID EX + EX EX ID EX + ID erzeugt einen Parse-Baum, der nach der alten Grammatik auch legal wäre. Statt S a a S a Besser: S a S a a Erzeugt einen anderen Parse-Baum (u.u. inkompatibel!) Problem: Gegeben S a S a b S b ɛ ( alle Palindrome aus a und b mit gerader Länge ) Kein LR-Parser möglich! Im Allgemeinen: Zu zwei verschiedenen kontextfreien Grammatiken zu bestimmen, ob sie die gleiche Sprache erzeugen, ist unentscheidbar... Also: kein Algorithmus möglich, der immer funktioniert. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 4 / 22

5 Lösen von SHIFT/REDUCE-Konflikten Spezialfall: Präzedenz von Operatoren festlegen: Grammatik: EX ID EX + EX EX * EX Ziel: Standard-Arithmetische Ausdrücke mit Punkt-Vor-Strich. Lösung: Präzedenz und Assoziativität festlegen. Idee: EX OP1 EX liegt auf dem Stack, OP2 steht im Input. Wenn OP1 Präzedenz vor OP2 hat: Reduzieren. Sonst: Shift! Erweiterung: EX OP1 EX liegt auf dem Stack, OP1 steht im Input. Wenn OP1 linksassoziativ ist: Reduzieren. Sonst: Shift! Damit z.b. Problem bei Bool-Ausdrücken in E lösbar. (Übung) Einfach, aber nur in Spezialfällen anwendbar. Beispiel! Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 5 / 22

6 REDUCE/REDUCE-Konflikte Ursache: uneindeutige Grammatik assignment : ID EQUALS NUMBER ID EQUALS expression expression : expression PLUS expression expression MINUS expression LPAREN expression RPAREN NUMBER Input: a := 5 (komplett konsumiert) Stack: ID EQUALS NUMBER Mögliche Reduktionen: Alles assignment, oder NUMBER expression. Lösung 1: Auflösungsstrategie: größere Reduktion vor kleinerer Reduktion Lösung 2: Grammatik eindeutig(er) machen, und hoffen dass der Parser Generator gute Fehlermeldungen liefert. PLY Dokumentation: To try and figure it out, you ll probably have to look at your grammar and the contents of the parser.out debugging file with an appropriately high level of caffeination. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 6 / 22

7 GLR-Parser LR-Parsen geht i.a. nicht ohne Konflikte. Idee: Konflikte nicht verhindern/vermeiden. Jeder Konflikt kann auf 2 (oder mehr) Arten aufgelöst werden. Warum nicht alle Problemlösungen gleichzeitig ausprobieren? Bei Konflikt: Stack + Zustandsautomat + Inputposition duplizieren, beide Möglichkeiten parallel weiterlaufen lassen. Tatsächliche Implementierung verwendet Bäume an Stelle von Stacks, weitere Optimierungen... Ergebnis: alle möglichen Parse-Bäume Laufzeitkosten: O(Inputgröße 3 ) Worst-Case. Für (LA-)LR-Grammatiken: Verhalten, Preformance wie LR-Parser Für mehrdeutige Grammatiken: Mehrere Ergebnisse, Auswahl nötig! Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 7 / 22

8 Mehr zu Parsern und LL(k)-Grammatiken Warum mehr Informationen über (LL(k))-Parser? Es gibt Alternativen zu (LA-)LR - Parsern... und diese sind praxisrelevant... und sie verhalten sich anders als (LA)LR - Parser. Die Chancen, dass diese später verwendet werden, sind hoch. Verwandtschaft mit handgeschriebenen Parsern. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 8 / 22

9 Theorie zu LL(k) - Parsern (1) Genau wie bei LR-Parsern: Ein Stack Eine Input-Quelle (aus der Terminalsymbole kommen) Ein Zustandsautomat, der von der Input-Quelle lesen kann, und Dinge auf den Stack legen kann und vom Stack herunter nehmen kann Anders als beim LR-Parser: Zu Beginn: Startsymbol der Grammatik liegt auf dem Stack Statt Shift: Drop Wenn oben auf dem Stack ein Terminalsymbol steht: Falls dieses auch im Input steht, so werden beide entfernt. Sonst: Fehler! Statt Reduce: Expand Wenn oben auf dem Stack ein Nichtterminalsymbol steht: Nimm das Nichtterminal vom Stack, und lege die rechte Seite einer passenden Produktion rückwärts auf den Stack Wenn Stack am Ende leer: Erfolg Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 9 / 22

10 Beispiel Stack Input E a + 3 * b E A M a + 3 * b E A MM P a + 3 * b E A MM ID a + 3 * b D A MM + 3 * b E A + 3 * b E Grammatik: Expr MultExpr Additions A M * b D Additions ɛ + MultExpr Additions A M 3 * b E MultExpr Particle MoreMult A MM P 3 * b E MoreMult ɛ * Particle MoreMult A MM NUM 3 * b D Particle IDENTIFIER NUMBER A MM * b E A MM P * * b D A MM P b E A MM ID b D A MM E A E leer Parse-Vorgang erfolgreich Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 10 / 22

11 Theorie zu LL(k) - Parsern (2) Der Zustandsautomat muss (wie bei LR-Parsern) entscheiden, was zu tun ist. Die Entscheidung ob Drop oder Expand ist einfach: Wenn oben auf dem Stack ein Terminalsymbol liegt, geht nur Drop, und sonst geht nur Expand. Die Entscheidung, anhand welcher Grammatikregel expandiert wird, hängt vom Input ab. Der Zustandsautomat betrachtet die kommenden k Token, und trifft dann eine Entscheidung. Vorteil: Bei endlichem k ist der Parse-Aufwand linear in der Input-Größe. Nachteil: Die Entscheidung, welche Produktion zu verwenden ist, muss mit nur k Token treffbar sein. Nachteil 2: Linksrekursive Produktionen sind nicht möglich Bsp.: E id E + id (Stack overflow!) Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 11 / 22

12 Probleme bei LL(k) - Parsern Alternativen brauchen unterschiedliches Präfix. Beispiel C (vereinfacht): Program Vardecl FuncDecl FuncDecl Type ID ( ) ; VarDecl Type ID ; Type IDENTIFIER Pointers Pointers ɛ * Pointers Input: int *******... In Program Entscheidung nötig: Ersetzen mit Vardecl oder FuncDecl? Dazu nötige Information: Kommt eine Klammer nach dem Typ und dem Namen? Aber: Typ kann beliebig lang sein! k Token Lookahead reichen nicht. Grundlegendes Problem: Verschiedene Produktionen fangen mit den gleichen Token an. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 12 / 22

13 Probleme bei LL(k)-Parsern Formal: 2 Arten von Konflikten: FIRST/FIRST: A B C, B und C fangen gleich an. Problem: A liegt oben auf dem Stack - soll nach B oder C expandiert werden? FIRST/FOLLOW: (nur bei ɛ-produktionen) A1 B C A2 B X B ɛ D C und D fangen gleich an. B liegt oben auf dem Stack, passender Input für D und C kommt. Problem: Soll nach D expandiert werden, oder soll nach ɛ expandiert werden? Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 13 / 22

14 Lösungen Linksrekursion kann (immer) eliminiert werden. (Dabei entstehen u.u. FIRST/FIRST-Konflikte.) recursion#removing_left_recursion FIRST/FOLLOW - Konflikte können durch Substitution aufgelöst werden, dadurch entstehen u.u. neue FIRST/FIRST - Konflikte. FIRST/FIRST - Konflikte lassen sich manchmal durch Left Factoring auflösen. Beispiel für Left Factoring : Program Vardecl FuncDecl problematisch, Anfang gleich. Stattdessen: Program Type ID VardeclOrFuncDeclRest VardeclOrFuncDeclRest ; ( ) ; Achtung: Diese Lösungsstrategien können den Parse-Baum einer erkannten Sprache ändern - dies lässt sich meist hinterher mit AST - Transformationen beheben. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 14 / 22

15 Linksrekursion vs. Assoziativität Beispiel: Entfernen von Linksrekursion ändert die Assoziativität von arithmetischen Ausdrücken! Linksrekursive Grammatik: EX ID EX + ID EX - ID Äquivalente rechtsrekursive Grammatik: EX ID ID + EX ID - EX Erzeugt selbe Sprache, aber: Assoziativität anders. Parse-Baum zu a - b - c wird wie a - (b - c) geparst... Lösung: Hinterher AST zurechttransformieren. Einige Parser-Generatoren (z.b. ANTLR) können dies automatisch, wenn man in der Grammatik die Assoziativität angibt. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 15 / 22

16 Grundlagen rekursiv absteigender Parser Pro Nichtterminalsymbol eine Funktion Funktion betrachtet die nächsten k Token im Input, entscheidet dann, welche Produktion verwendet werden soll. Wenn die Produktion ein Nichtterminalsymbol beinhaltet, so wird dessen Funktion aufgerufen (Rekursion!) Wenn die Produktion ein Terminalsymbol beinhaltet, so wird versucht, dieses aus dem Input zu konsumieren. Falls nicht vorhanden: Fehler! Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 16 / 22

17 Beispiel für rekursiv absteigenden Parser # vordefiniert: # * next_token gibt nächstes # zurück, ohne zu konsumieren # * consume konsumiert das über- # gebene Token, panic bei mis- # match # * panic bricht das Parsen er- # folglos ab def expr(): mult_expr() additions() def additions(): if next_token() == + : consume( + ) mult_expr() additions() def mult_expr(): particle() more_mult() def more_mult(): if next_token() == * : consume( * ) particle() more_mult() def particle(): if next_token() == ID: consume(id) elif next_token() == NUMBER: consume(number) else: panic() Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 17 / 22

18 Ähnlichkeiten zwischen LL(k)-Parsern und Rekursiv Absteigenden Parsern Vergleichbar dann, wenn die Entscheidung für eine Produktion final ist (d.h. kein Zurücklegen von Tokens in den Input und Backtracking) Wenn zugrundeliegende Grammatik in LL(k), dann: Parser existiert und funktioniert. Übungsaufgabe: Vergleich zw. Funktionsaufruf-Stack und LL(k) - Stack! Parser kann von Hand geschrieben werden (anhand der Grammatik) Parsen ist linear in Inputgröße (damit meist akzeptabel schnell) Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 18 / 22

19 Rekursiv absteigende Parser mit Backtracking Wenn Grammatik nicht in LL(k): Rekursiver Abstieg immer noch möglich Wenn mit k Token Lookahead Entscheidung nicht möglich: Eine Produktion auswählen und versuchen mit ihr zu parsen. Bei Misserfolg: Input wiederherstellen, andere Produktion auswählen. Endgültiger Misserfolg wenn alle Produktionen fehlschlagen Backtracking! Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 19 / 22

20 Beispiel Backtracking beim Parsen def Program(): x = getinputposition() try: VarDecl() return catch ParseException: setinputposition(x) FuncDecl() def VarDecl(): Type() consume(id) consume( ; ) def FuncDecl(): Type() consume(id) consume( ( ) consume( ) ) consume( ; ) def Type(): consume(id) while next_token() == * : consume( * ) Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 20 / 22

21 Backtracking: Probleme Je nach Grammatik/Input u.u. sehr teuer (exponentiell mit Inputgröße als Basis!) Beispiel: A a A b a A c y Problem: Für die selbe Input-Position wird immer wieder die Funktion für A aufgerufen. Lösung: Memoization. Jeder Aufruf der Funktion für A merkt sich seine Inputposition das Parse-Ergebnis Benötigt Laufzeit in O(Inputgröße), sowie Speicher in O(Inputgröße * Grammatikgröße) Wird auch Packrat-Parsing genannt. Verwandt: Sogenannte PEG-Parser ( Parsing Expression Grammar ). Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 21 / 22

22 Fazit LL(k) oder LR-Parser? Je nach Sprache das Passende auswählen! Wenn möglich, LL(k) statt Backtracking/Memoization. Wenn möglich, LALR statt GLR. Leitfaden für Sprachdesigner: Sprache so einfach parsebar machen wie möglich. Übung Ü1 Informatik 2 WS 2015/16 Mehr zu Parsern und LL(k)-Grammatiken Folie 22 / 22