Compilerbau Bücher?
-
µ schrieb:
Hier schonmal ein sehr gutes Skript über die Konstruktion von Bottom-Up Parsern:
http://amor.cms.hu-berlin.de/~kunert/papers/lr-analyse/
(LR0, LR1, SLR und LALR Parsergeneratoren habe ich vor kurzem implementiert, aber in C#. Das Skript war jedenfalls eine große Hilfe)Hmm... ^^ ich sehe griechische Buchstaben, Buchstaben mit Indizes und verklausulierte Sätze.
µ schrieb:
Enno schrieb:
Ich hoffe ich bin nicht schuld.
Ach was. Der Montag ist Schuld
Joah, noch vier Montage und dann ist endlich Wochenende.
-
So meine Damen und Herren.
Meine Aufgabe ist nun klar def..
Ich soll nur diesen geposteten Teil Code Compilieren können. Es geht nur um das nicht mehr. Hat er selbst erfunden. Hat er vorher aber auch nicht gesagt der Schlaumeier. Also soll ich einen Compiler für diesen Code abschnitt schreiben. Wichtig oder der schwierige Teil laut ihm ist das OOP JS beizubringen. D.h. heißt auch ich kann mir den Grammatik kram wohl sparen oder?
Xin schrieb:
µ schrieb:
Enno schrieb:
Ich hoffe ich bin nicht schuld.
Ach was. Der Montag ist Schuld
Joah, noch vier Montage und dann ist endlich Wochenende.
YAAAYY
-
Enno schrieb:
So meine Damen und Herren.
Meine Aufgabe ist nun klar def..
Ich soll nur diesen geposteten Teil Code Compilieren können. Es geht nur um das nicht mehr.Schade, schreib ein Programm, das den geladenen Code mit diesem Programm vergleicht und wenn das passt, schreibst Du einen festgelegten Text auf die Platte. Problem gelöst
Enno schrieb:
Hat er selbst erfunden. Hat er vorher aber auch nicht gesagt der Schlaumeier. Also soll ich einen Compiler für diesen Code abschnitt schreiben. Wichtig oder der schwierige Teil laut ihm ist das OOP JS beizubringen.
... Du meinst JS?
Ich glaube, ich verstehe die Aufgabe jetzt weniger, denn je. ^^
Enno schrieb:
D.h. heißt auch ich kann mir den Grammatik kram wohl sparen oder?
Nicht, wenn die Aufgabe einen Sinn ergeben soll.
-
Xin schrieb:
Enno schrieb:
So meine Damen und Herren.
Meine Aufgabe ist nun klar def..
Ich soll nur diesen geposteten Teil Code Compilieren können. Es geht nur um das nicht mehr.Schade, schreib ein Programm, das den geladenen Code mit diesem Programm vergleicht und wenn das passt, schreibst Du einen festgelegten Text auf die Platte. Problem gelöst
Ehm ... was?^^
Xin schrieb:
Enno schrieb:
Hat er selbst erfunden. Hat er vorher aber auch nicht gesagt der Schlaumeier. Also soll ich einen Compiler für diesen Code abschnitt schreiben. Wichtig oder der schwierige Teil laut ihm ist das OOP JS beizubringen.
... Du meinst JS?
Ich glaube, ich verstehe die Aufgabe jetzt weniger, denn je. ^^
Oh, ich glaub das war nur verwirrend geschrieben.
Er meinte das Problem ist in JS die OOP also die class und vererbung rein zubekommen.
Xin schrieb:
Enno schrieb:
D.h. heißt auch ich kann mir den Grammatik kram wohl sparen oder?
Nicht, wenn die Aufgabe einen Sinn ergeben soll.
Mist!
-
Enno schrieb:
Xin schrieb:
Enno schrieb:
So meine Damen und Herren.
Meine Aufgabe ist nun klar def..
Ich soll nur diesen geposteten Teil Code Compilieren können. Es geht nur um das nicht mehr.Schade, schreib ein Programm, das den geladenen Code mit diesem Programm vergleicht und wenn das passt, schreibst Du einen festgelegten Text auf die Platte. Problem gelöst
Ehm ... was?^^
Wenn dein "Compiler" nur das von dir gepostete Script kompilieren können soll, dann Prüfst du eben, ob die Eingabe eben genau diesem Script entspricht. Wenn ja, schreibst du die vorher per Hand ausgeklügelte und in deinem "Compiler" hart kodierte JavaScript-Entsprechung in die Ausgabedatei und du hast fertig.
-
Swordfish schrieb:
Enno schrieb:
Xin schrieb:
Enno schrieb:
So meine Damen und Herren.
Meine Aufgabe ist nun klar def..
Ich soll nur diesen geposteten Teil Code Compilieren können. Es geht nur um das nicht mehr.Schade, schreib ein Programm, das den geladenen Code mit diesem Programm vergleicht und wenn das passt, schreibst Du einen festgelegten Text auf die Platte. Problem gelöst
Ehm ... was?^^
Wenn dein "Compiler" nur das von dir gepostete Script kompilieren können soll, dann Prüfst du eben, ob die Eingabe eben genau diesem Script entspricht. Wenn ja, schreibst du die vorher per Hand ausgeklügelte und in deinem "Compiler" hart kodierte JavaScript-Entsprechung in die Ausgabedatei und du hast fertig.
Danke.
Ob ich da nun aber ein halbes Jahr dran hocke na ich weiß nicht. xD Der hat sicher noch was mit mir vor.
-
Die dort beschriebenen Konzepte sollten mehr als ausreichen:
http://www.c-plusplus.net/forum/268247Und wenn du nur den Lexer (Scanner) übernimmst oder dich zumindest inspirieren lässt.
-
fghfgh schrieb:
Die dort beschriebenen Konzepte sollten mehr als ausreichen:
http://www.c-plusplus.net/forum/268247Und wenn du nur den Lexer (Scanner) übernimmst oder dich zumindest inspirieren lässt.
Danke.
-
µ schrieb:
Enno schrieb:
Lexer- und Parsergeneratoren muss ich selber machen. Also er meinte ich soll alles selber schreiben.
Autsch.
Nunja, weder ein Lexer noch ein einfacher LL Parser sind Teufelswerk, solang die Grammtik klar ist.
-
maximAL schrieb:
µ schrieb:
Enno schrieb:
Lexer- und Parsergeneratoren muss ich selber machen. Also er meinte ich soll alles selber schreiben.
Autsch.
Nunja, weder ein Lexer noch ein einfacher LL Parser sind Teufelswerk, solang die Grammtik klar ist.
Also ich muss sagen das mit der Grammatik finde ich ziemlich schwer. ^^
Bin hart am tüfteln hier.
-
Enno schrieb:
maximAL schrieb:
µ schrieb:
Enno schrieb:
Lexer- und Parsergeneratoren muss ich selber machen. Also er meinte ich soll alles selber schreiben.
Autsch.
Nunja, weder ein Lexer noch ein einfacher LL Parser sind Teufelswerk, solang die Grammtik klar ist.
Also ich muss sagen das mit der Grammatik finde ich ziemlich schwer. ^^
Bin hart am tüfteln hier.Ja, aber das zu verstehen ist auch das Wichtigste an der ganzen Sache
In der Praxis muss man selten einen Parser schreiben, aber doch häufiger irgendwelche Skriptsprachen verwenden und da sollte man die Grammatik, wie sie meistens in der Doku steht, auch lesen können
-
maximAL schrieb:
Enno schrieb:
maximAL schrieb:
µ schrieb:
Enno schrieb:
Lexer- und Parsergeneratoren muss ich selber machen. Also er meinte ich soll alles selber schreiben.
Autsch.
Nunja, weder ein Lexer noch ein einfacher LL Parser sind Teufelswerk, solang die Grammtik klar ist.
Also ich muss sagen das mit der Grammatik finde ich ziemlich schwer. ^^
Bin hart am tüfteln hier.Ja, aber das zu verstehen ist auch das Wichtigste an der ganzen Sache
In der Praxis muss man selten einen Parser schreiben, aber doch häufiger irgendwelche Skriptsprachen verwenden und da sollte man die Grammatik, wie sie meistens in der Doku steht, auch lesen könnenJap. Ich kämpfe.
Aber das Script was oben gepostet wurde ist supi.
-
Enno schrieb:
Jap. Ich kämpfe.
Aber das Script was oben gepostet wurde ist supi. "LR(k)-Analyse für Pragmatiker" ?
Der Anfang ist vielleicht etwas schwierig aber eigentlich ist das Skript mit sehr vielen Beispielen und viel Prosa angereichert. Die Grundlagen zu Grammatiken kannst Du bestimmt bei Wikipedia nachlesen, bei sonstigen Schwierigkeiten einfach nachfragen.
maximAL schrieb:
µ schrieb:
Enno schrieb:
Lexer- und Parsergeneratoren muss ich selber machen. Also er meinte ich soll alles selber schreiben.
Autsch.
Nunja, weder ein Lexer noch ein einfacher LL Parser sind Teufelswerk, solang die Grammtik klar ist.
Ein-Wort-Zitate sind schon etwas sinnentstellend.
Trotzdem an der Stelle nochmal zu LL/TopDown-Parsern: Es ist immer noch nicht so ganz klar wie die Aufgabenstellung aussieht. Dass nur der Beispielcode kompiliert werden soll ist offensichtlich Unsinn. Hier muss nochmal mit dem Ausbilder gesprochen werden über die exakte Sprache die implementiert werden soll.
Dann kann man abwägen:
1. Einen LL-Parser direkt, d.h. per Rekursiven Abstieg* implementieren. Das kommt in Frage wenn die Sprache sehr einfach ist. Sie muss eigentlich so einfach sein, dass man Mehrdeutigkeiten "sieht" bzw. die First- und Follow-Mengen fast trivial sind. Jede Änderung an der Grammatik wäre mindestens unbequem.
2. Einen Tabellengesteuerten LL-Parser ("Nichtrekursive prädiktive Syntaxanalyse"). Wie kommt man an die Tabelle? Darf er LL-Generatoren verwenden um wenigstens die Tabelle zu erstellen und diese nur noch abarbeiten? Muss die Tabelle von Hand erstellt werden (Stift&Papier?), dann ist jede Änderung an der Grammatik die reine Folter. Genauso wie bei LR-Parsern. Deshalb hier auch fast der einfachste Weg, einen LL-Parsergenerator zu schreiben. Und schon stellt sich die Frage: Warum dann nicht direkt einen LR-Generator, der kaum mehr Mühe macht, aber die "bessere" Variante ist.Übrigens: Dummerweise müssen Grammatiken auch oft transformiert werden, damit ein Top-Down-Parser sie bewältigen kann. Gut daran ist allerdings, dass diese Transformationen in vielen Fällen rein mechanisch durchgeführt werder können. Also nur ein kleines Manko.
@Op
Sprich mit Deinem Betreuer nochmal über all diese Dinge. Ich habe den leisen Verdacht, dass er keine Ahnung hat und die Aufgabe mit RegEx und String-Replace anpacken würde
-
Irgendwie verstehe ich von dem Skript nicht ganz so viel.
Gibt es eigentlich eine C++ Grammatik? Oder gibt es einfachere Seiten oder PDF's aus den ich lernen könnte? Weiß da jemand was?
Danke.
-
µ schrieb:
Trotzdem an der Stelle nochmal zu LL/TopDown-Parsern: Es ist immer noch nicht so ganz klar wie die Aufgabenstellung aussieht. Dass nur der Beispielcode kompiliert werden soll ist offensichtlich Unsinn. Hier muss nochmal mit dem Ausbilder gesprochen werden über die exakte Sprache die implementiert werden soll.
Ich glaube, es geht wirklich nur darum ein kleines Subset von JS mit eben diesen Erweiterungen zu parsen. Der gezeigte Codeschnipsel wird wahrscheinlich alle wirklich geforderten Konstrukte beinhalten. Also wird hier kein vollständiger Parser für eine wirkliche Programmiersprache entworfen. Im Studium haben wir bei Compilerbau anfangs ähnliches gemacht und am Ende einen "vollständigen" Compiler für PL/0 geschrieben.
µ schrieb:
1. Einen LL-Parser direkt, d.h. per Rekursiven Abstieg* implementieren. Das kommt in Frage wenn die Sprache sehr einfach ist. Sie muss eigentlich so einfach sein, dass man Mehrdeutigkeiten "sieht" bzw. die First- und Follow-Mengen fast trivial sind. Jede Änderung an der Grammatik wäre mindestens unbequem.
Ich vermute fast, dass ein einfacher rekursiver Parser reicht. Warum auch nicht, damit kann man problemlos LL* parsen.
An der Grammatik sollte natürlich eher wenig geändert werden, aber er soll ja auch keine neue Programmiersprache entwerfen.Enno schrieb:
Gibt es eigentlich eine C++ Grammatik?
Vergiss es, C++ ist eine zusammengefrickelter Haufen #@$%, dafür findest du keine vollständige Grammatik.
-
Danke erstmal für deine Antwort. Also wenn ich das jetzt richtig verstehe, brauch ich eine LL grammatik? Sowas hier?
Oder sollte ich wirklich diesen ganzen Grammatik kram lernen weil es wichtig ist?
-
Naja, du brauchst eine Grammatik für die Sprache, die du parsen willst. Diese sollte als BNF bzw. EBNF vorliegen.
Dann könntest du prüfen, ob diese Grammatik die LL(k)-Eigenschaft hat, also sich mit einem LL-Parser mit einem Lookahead von k Token parsen lässt.
Allerdings will ich bezweifeln, dass du die Formale Definition von LL(k) Grammatiken wie auf der Wikipedia-Seite wirklich durchschauen musst (das haben wir uns nichtmal an meiner dämlichen FH gemacht
).
Wichtig ist erstmal: BNF bzw. EBNF verstehen. Eigentlich würde ich das als Grundlagenwissen voraussetzen, wenn ihr schon Compilerbau habt.
Müsst ihr die Grammatik für diese "Sprache" selbst entwerfen oder wird das (teilweise) vorgegen?
Eigentlich sollte die Grammatik für so ein Einführungsbeispiel eh recht einfach gewählt sein und sich mit einem LL-Parser verarbeiten lassen. Eventuelle Probleme (beispielsweise wenn ein Lookahead (also k) von mehr als 1 nötig ist) erkennt man da meistens intuitiv.
Versuch nicht die LL(k)-Eigentschaft deiner Grammatik formal zu beweisen, solangs keiner verlangt.
-
maximAL schrieb:
Vergiss es, C++ ist eine zusammengefrickelter Haufen #@$%, dafür findest du keine vollständige Grammatik.
Wenn man den Standard ignoriert, hast du Recht. Wenn man das aber nicht tut, hat man eine fertige Grammatik. Diese ist zwar nicht in LR, aber es gibt sie.
-
otze_logout schrieb:
Wenn man den Standard ignoriert, hast du Recht. Wenn man das aber nicht tut, hat man eine fertige Grammatik. Diese ist zwar nicht in LR, aber es gibt sie.
Die C++-Syntax ist nicht ausschließlich durch eine Grammatik spezifiziert. Der Vorposter spielt wahrscheinlich auf solche Auflösungsregeln für Mehrdeutigkeiten wie in Abschnitt 8.2 des Standards an.
-
Mit meinem EBNF-Parser kannst du überprüfen, ob der Code zu deiner EBNF-Definition paßt (bzw. umgekehrt die EBNF-Definition solange verändern, bis sie die Beispielprogramme korrekt interpretiert).
