Freie TextTransformer Projekte
Freie TextTransformer Projekte
Die Anfänge des Delphi.ttp Projekts zur Entwicklung eines Parsers für die Programmiersprache Delphi reichen bis in die Anfänge der Entwicklung des TextTransformers zurück. Das eigentliche Ziel war dabei, einen Übersetzer nach C++ zu schaffen, um es einem C++-Entwickler leichter zu machen, Delphi-Komponenten an das eigene Programm anzupassen. Das würde letztlich auch dem TextTransformer selbst zugute kommen, da in ihm viele solcher Komponenten verwendet werden.
Die größte Schwierigkeit bei der Entwicklung eines Delphi-Parsers besteht darin, dass es für diese Programmiersprache keinen offiziellen Standard gibt. Die Spezifikation der Sprache wurde in erster Linie der Hilfe der Delphi-Entwicklungsumgebung entnommen. Darin sind die Informationen bruchstückhaft verstreut, insgesamt unvollständig und uneinheitlich. Zudem wurde Delphi ständig weiterentwickelt.
In der Zwischenzeit gibt es mit dem "reference guide" zu "Free Pascal" einen gut gelungenen Versuch die Delphi-Spezifikation darzustellen.
Auch hier gibt es Unstimmigkeiten in den Details. Dennoch wurde das Parser-Projekt anhand dieser Referenz nochmals überarbeitet, wobei insbesondere auch die Namensgebungen angepasst wurde. Eine Identität besteht aber schon deshalb nicht, weil die Regeln im TextTransformer Parser aus Effizienzgründen möglichst LL(1)-konform gehalten werden.
Der hier präsentierte Parser dürfte in etwa den Stand von Delphi 5 darstellen. Er ist in der Lage die gesamte VCL zu parsen, die zum CBuilder 6 gehört. Dabei setzt er voraus, dass der zu parsende Code syntaktisch korrekt ist. Er kann nicht dazu verwendet werden die Korrektheit zu überprüfen, weil er auch Konstruktionen zulässt, die der Delphi-Compiler zurückweisen würde.
Dr. Hans-Peter Diettrich hat mich eine zeitlang bei der Entwicklung des Parsers unterstützt; dafür meinen Dank!
Die Projektoptionen zum Parser/Scanner weichen in drei Punkten von den Standardeinstellungen ab:
|
Die Vorausschaltung des Präprozessors erlaubt es, den Parser direkt an der VCL zu testen.
Der zweite Punkt berücksichtigt schlicht die Sprachdefinition von Delphi.
Der letzte Punkt ist nötig, da in Delphi auch Schlüsselworte wie "Index" oder "end" als Namen für Variablen und Parameter verwendet werden dürfen. Der Nachteil dieser Option ist, dass unerwartete Schlüsselworte auch als Bezeichner erkannt werden können, was dann die Fehlersuche im Parser erschwert.
In Delphi können Kommentare in dreierlei Form geschrieben werden:
|
Diese drei Formen sind in Delphi.ttp zu einer "COMMENT"-Produktion kombiniert worden, die in den Projektoptionen als Einschluss gesetzt ist. Eine Verschachtelung der Kommentare wurde nicht zugelassen, weil es in der VCL Fälle gibt, in denen entsprechend erforderliche schließende Klammern fehlen. Das Vorkommen einer Kommentarart innerhalb einer anderen ist aber zulässig. ( Letzteres gilt nicht für den altenativ verwendbaren regulären Ausdruck "IGNORE", der im Projekt belassen, aber nicht verwendet wurde.)
Wenn das Projekt kompiliert wird, gibt es einige Warnungen der Art, dass bestimmte Token Strart und Nachfolger löschbarer Strukturen sind. Sie resultieren aus der Behandlung des Semikolons. Semikola trennen in Delphi sowohl ganze Strukturen als auch Unterstrukturen voneinenader ab, sind aber nicht immer notwendiger Bestandteil dieser Strukturen. In diesem TextTransformer-Projekt wird die schwierige Entscheidung, wann die Semikola notwendig und wann sie optional sind öfters dadurch vermieden, dass ihr Vorkommen in diesen Fällen als optional angenommen wird. Sei es als isolierte optionale Token oder als Alternative in Wiederholungen. Da der Parser voraussetzt, dass der Code korrekt ist, werden notwendige Semikola stets durch die optionalen Ausdrücke erkannt. Das Token nach dem Semikolon muss dann eindeutig über den weiteren Verlauf des Parsens entscheiden können. Diese löschbaren optionalen Semikola verursachen aber die genannte Warnmeldungen.
Ein Beispiel für eine korrekte aber komplizierte Behandlung des Semikolons ist die Produktion "stmt_list". Diese Produktion spezifiziert eine Kette von Anweisungen. Gemäß dem obigen Verfahren könnte sie einfach auf folgende Weise formuliert werden:
stmt_list ::= ( stmt | ";" )+
Alle Token, mit denen eine Anweisung "stmt" beginnen und enden können, verursachen dann eine Warnmeldung.
Zur Unterdrückung dieser Warnungen kann mit der Vorausschau "is_end_of_stmt_list" getestet werden, ob aus das Semikolon ein ein Token folgt, mit dem Ketten von Anweisungen beendet werden. Vor den Schlüsselworten "end", "except", "finalization", "finally" und "until" braucht nämlich eine Anweisung nicht mit einem Semikolon abgeschlossen zu werden.
| stmt_list ::= | ";" stmt_list_not_empty? | stmt_list_not_empty |
| stmt_list_not_empty ::= | stmt ( IF(!is_end_of_stmt_list()) ";" stmt ELSE ";" END )* |
Es gibt eine Reihe von Versuche die Delphi-Grammatik darzustellen, die aber nicht weit gediehen sind. Erwähnenswert scheint:
http://www.felix-colibri.com/papers/compilers/delphi_5_grammar/delphi_5_grammar.html
Diese Grammatik ist aber für den anscheinend hauseigenen Parsergenerator "GenCot" verfasst, und benötigt in einigen Fällen Ergänzungen um handgeschriebenen Code, der nicht veröffentlicht ist.
Weitere Grammatiken gibt es hier:
Bereits oben wurde erwähnt, dass der Parser die gesamte zum CBuilder 6 gehörige VCL parsen kann. Drüberhinaus absolviert er eine Testsuite, die aus den Tests von Free Pascal abgeleitet wurde.
Folgende Veränderungen wurden an der ursprünglichen Testsuite vorgenommen:
|
Letztes Update: 31.12.09
1.1.6 lokale Einstellungen der Kommentar-Produktionen so korrigiert, dass keine Zeichen ignoriert werden
1.1.5
1.1.0 absolviert Testsuite
1.0.2 : ein Fehler im regulären Ausdruck von CTRL_CHAR hatte einen Konflikt verschleiert. Die Grammatik für Typen wurde so überarbeitet, das der Konflikt vermieden wird und außerdem eine Vorausschau wegfällt.
| to the top |