2 Lexikalische Analyse - Westfälische Wilhelms-Universität Münster

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Lexikalische Analyse, LEX
im Rahmen des Seminars „Übersetzung von künstlichen Sprachen“
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Tim Majchrzak
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Karin Pietzonka

Inhaltsverzeichnis
1 Motivation .................................................................................................................. 1
2 Lexikalische Analyse ................................................................................................. 2
2.1 Einordnung der lexikalischen Analyse in den Compilerbau .............................. 2
2.1.1 Aufgaben der lexikalischen Analyse .......................................................... 3
2.1.2 Trennung der lexikalischen und syntaktischen Analyse ............................. 4
2.2 Das Verfahren der lexikalischen Analyse .......................................................... 5
2.2.1 Einstiegsbeispiel ......................................................................................... 5
2.2.2 Token .......................................................................................................... 6
2.2.3 Reguläre Ausdrücke .................................................................................... 7
2.2.4 Endliche Automaten ................................................................................... 8
2.2.5 Pattern-Matching / Tokenerkennung ........................................................ 10
2.2.6 Eingabepuffer ............................................................................................ 12
2.3 Probleme .......................................................................................................... 13
2.4 Aufwand und Optimierungsmöglichkeiten ...................................................... 14
3 Generierung eines Scanners ..................................................................................... 15
3.1 Anforderungen an einen Scanner ..................................................................... 15
3.2 Manuelle Generierung ...................................................................................... 16
3.3 Der Scannergenerator lex ................................................................................. 17
3.3.1 Einführung in lex und Darstellung seiner Vorteile ................................... 17
3.3.2 Arbeitsweise eines lex-Generators ............................................................ 18
3.3.3 Struktur eines lex-Programmes ................................................................. 19
3.4 Weitere Scannergeneratoren ............................................................................ 20
4 Zusammenfassung und Ausblick ............................................................................. 21
5 Literaturverzeichnis ................................................................................................. 23
II

Kapitel 1: Motivation
1 Motivation
Der Compilerbau gilt als eines der ältesten Gebiete in der praktischen Informatik.
Bereits in den 40er Jahren gab es die ersten Computer, welche Eingaben verarbeiten
mussten. Mit der schnellen Weiterentwicklung, hin zu neuen Programmiersprachen,
entwickelte sich auch der Compilerbau [ALSU08, S. 16 f]. Ein Compiler soll ein
Quellprogramm in ein Zielprogramm, meist Maschinensprache für die Verarbeitung
durch den jeweiligen Rechner, umwandeln. Moderne Compiler werden dazu heutzutage
in verschiedene Phasen gegliedert.
Die lexikalische Analyse ist, als erster Abschnitt einer der wichtigsten [Br04]. Ihre
Aufgabe ist, das Quellprogramm einzulesen und für die weitere Verarbeitung
vorzubereiten. Ohne den Einleseprozess innerhalb der lexikalischen Analyse würde der
Compiler das Quellprogramm nicht erhalten und ein Kompilierungsvorgang wäre somit
erst gar nicht möglich. Außerdem muss der eingelesene Text strukturiert werden, um
den weiteren Umwandlungsprozess erheblich zu erleichtern. Die strukturierten und für
den Rechner leichter zu verarbeitenden Ergebnisse aus der lexikalischen Analyse
können dann an den Parser und somit an den weiteren Umwandlungsprozess durch den
Compiler weitergegeben werden. Aus diesem Grund soll in dieser Arbeit der Einlese-
und Verarbeitungsprozess der lexikalischen Analyse genauer betrachtet und analysiert
werden.
Zu diesem Zweck wird die lexikalische Analyse mit ihren spezifischen Aufgaben
zunächst noch einmal genauer in den Prozess des Kompilierens eingegliedert. In
Kapitel 2 werden die grundlegenden Begriffe und Bestandteile der lexikalischen
Analyse erläutert, um dann den Prozess der Mustererkennung und Vereinfachung zu
klären. Anschließend soll in Kapitel 3 das Verfahren automatisiert und durch
Implementierung von Generatoren für Nutzer erleichtert werden. Dazu wird der
Scannergenerator lex und seine Arbeitsweise vorgestellt. Abschließend erfolgen eine
Zusammenfassung der Arbeit sowie ein kurzer Ausblick auf künftige Entwicklungen.
1

Kapitel 2: Lexikalische Analyse
2 Lexikalische Analyse
2.1 Einordnung der lexikalischen Analyse in den Compilerbau
Ein Compiler besteht aus verschiedenen Phasen, welche jeweils für bestimmte
Aufgaben zuständig sind [He03, S. 4]. Die Aufgaben und Techniken des Compilerbaus
sind im Allgemeinen dort anzutreffen, wo Zeichenfolgen sequentiell verarbeitet werden
[Br04].
Quellprogramm
Lexikalische
Analyse
Syntaktische
Analyse
Semantische
Analyse
Zwischencode
erzeugung
Programmoptimierung
Codegenerierung
Zielprogramm
Frontend
(Analyse
phase)
Backend
(Synthese
phase)
Abbildung 1: Phasen des Compilers
Quelle: Vgl. [He03, S. 4].
Abbildung 1 zeigt, dass die Phasen des Compilers in zwei große Bereiche gegliedert
werden, welche wiederum in je drei Teilaufgaben unterteilt werden [WH09, S. 57]. Der
2

Kapitel 2: Lexikalische Analyse
erste Bereich ist die Analysephase (Frontend), welche den eingelesenen Quelltext
analysiert, strukturiert und auf Fehler überprüft. Sie wird unterteilt in die lexikalische,
die syntaktische und die semantische Analyse. Den zweiten Bereich stellt die
Synthesephase (Backend) dar, deren Aufgabe die Erzeugung eines Zielprogramms ist.
Die drei Aufgabenbereiche sind die Zwischencodeerzeugung, die
Programmoptimierung und die Codegenerierung.
Die lexikalische Analyse bildet somit die erste Phase eines Compilers, welche das
unbearbeitete Quellprogramm einliest.
2.1.1 Aufgaben der lexikalischen Analyse
Die lexikalische Analyse lässt sich, wie Abbildung 2 zeigt, in zwei aufeinanderfolgende
Aufgabenbereiche unterteilen.
Scannen
Lexikalische Analyse
Lexikalische
Analyse i.e.S.
Abbildung 2: Aufgabenbereiche der lexikalischen Analyse
Im ersten Schritt liest bzw. scannt die lexikalische Analyse die Eingabezeichen des
Quellprogramms mit Hilfe eines Lexers ein. Durch den Prozess des Scannens bzw.
Abtastens wird der Lexer auch häufig als Scanner bezeichnet. Damit der Parser in der
nächsten Phase keine für das Ergebnis unnötigen Zeichen verarbeiten muss, entfernt der
Lexer Kommentare und Leerraum, wie z.B. Leerzeichen, Tabulatoren, Zeilenwechsel
und andere Trennzeichen. Außerdem kann der Lexer Fehlermeldungen zuordnen.
Lexikalische Fehler wie beispielsweise eine zu große Zahl, die nicht dem Wertebereich
entspricht, oder ein Kommentar, der nicht ordnungsgemäß mit „*/“ abgeschlossen wird,
werden als Fehler gespeichert. Der Compiler übernimmt hierzu die Position des Tokens
und verknüpft den Fehler mit der entsprechenden Zeilennummer. In einigen Compilern
besteht die Möglichkeit, dass im Zuge der lexikalischen Analyse eine Kopie des
Quellprogramms angelegt wird, um Fehlermeldungen direkt an der richtigen Stelle
einzufügen. Dies dient in den nächsten Phasen des Compilers einer einfacheren
Auffindung.
3

Kapitel 2: Lexikalische Analyse
Die Hauptaufgabe des Lexers ist die lexikalische Analyse im engeren Sinne. Die
eingelesenen Zeichen werden nach bestimmten Textmustern abgesucht und die
erkannten Muster, auch Lexeme genannt, werden gruppiert. Für die identifizierten
Gruppen von gleichen bzw. ähnlichen Textteilen werden sogenannte Token definiert.
Die Ausgabe der lexikalischen Analyse ist somit eine Folge von Token, welche an den
Parser zur syntaktischen Analyse gesendet wird [Wi02].
Der Lexer kann durch die Möglichkeit der Erkennung verschiedenster Textzeichen und
das Ersetzen von Textmustern, in einem anderen Kontext der Textverarbeitung, auch
die Funktionen eines Präprozessors übernehmen, falls ein solcher fehlt. Dieser
verarbeitet und entfernt, ähnlich wie der Lexer, beispielsweise Kommentare und
Zeilenumbrüche.
2.1.2 Trennung der lexikalischen und syntaktischen Analyse
Generell könnte die lexikalische Analyse zusammen mit der syntaktischen Analyse
beschrieben werden, da diese beiden Phasen eng zusammenarbeiten. Eine Trennung,
wie sie hier vorgenommen wurde, ist allerdings aus verschiedenen Gründen sinnvoll
[Br04].
Zunächst dient eine Trennung der Vereinfachung des Entwurfs einer neuen Sprache, die
der Compiler verarbeiten soll. Müsste der Parser in der Syntaxanalyse eine Grammatik
einer Sprache verarbeiten, welche direkt auf den Eingabezeichen basiert, insbesondere
Zeichen, wie z. B. Leerraum oder Kommata, wäre der Parser erheblich komplexer.
Durch eine Trennung wird der Entwurf klarer und ergibt einen sauberen
Gesamtentwurf.
Ein weiterer Grund, der für eine Zerlegung der beiden Phasen spricht, ist die
Effizienzverbesserung des Compilers. Getrennte Aufgabenbereiche können spezifischer
und somit effizienter implementiert werden. Außerdem können so Techniken zur
Beschleunigung der lexikalischen Analyse ermöglicht werden, ohne die syntaktische
Analyse unnötig zu belasten.
Weiterhin ermöglicht eine Trennung der Phasen eine bessere Portabilität. Es können
Besonderheiten der Eingabegeräte berücksichtigt und ausschließlich auf den Scanner
4

Kapitel 2: Lexikalische Analyse
der lexikalischen Analyse beschränkt werden. Für diese Besonderheiten muss lediglich
ein separater Compileraufruf in Kauf genommen werden.
Eine häufige Implementierung der beiden Phasen beruht auf dem Aufruf des Lexers der
lexikalischen Analyse durch den Parser der Syntaxanalyse (scan on demand) [WH09,
S.59 f].
Quellprogramm
Token
Lexer Parser
getNextToken
Symboltabelle
Abbildung 3: Interaktion Lexer – Parser
…
Quelle: Vgl. [WH09, S. 59 f].
Wie Abbildung 3 zeigt, liest der Lexer zunächst Zeichen aus der Eingabe und gibt,
nachdem er ein Token identifiziert hat, dieses an den Parser zur syntaktischen Analyse
weiter. Mit dem Aufruf getNextToken veranlasst der Parser den Lexer die nächsten
Zeichen der Eingabe zu lesen. Gefundene Muster bzw. Lexeme und andere
Informationen, wie der Typ und die Stelle an der das Lexem das erste Mal aufgetaucht
ist, fügt der Lexer in die Symboltabelle ein. Diese können dann vom Parser entnommen
werden.
2.2 Das Verfahren der lexikalischen Analyse
2.2.1 Einstiegsbeispiel
Das Ziel der lexikalischen Analyse ist Muster bzw. Lexeme, d. h. vordefinierte
Zeichenfolgen, innerhalb der Eingabe zu erkennen und diese in Token zu übertragen.
Der Lexer erkennt ein Lexem als eine Instanz der festgelegten Tokenklasse. Hierbei
kann ein Token nur eine oder auch mehrere Ausprägungen, d. h. Muster, besitzen. Das
folgende Beispiel soll einen Einstieg in die Umwandlung von Mustern in Token geben.
Es können beliebige Tokenklassen, beispielsweise Satzbausteine, definiert werden. Die
lexikalische Analyse sucht in den Eingabezeichen nach den Mustern, die in einer
5

Kapitel 2: Lexikalische Analyse
Tokenklasse definiert wurden und ersetzt diese durch den Tokennamen. Nach dem
Prozess der lexikalischen Analyse würde der nachstehende deutsche Satz beispielsweise
wie folgt umgewandelt:
Ein Mann steigt in sein blaues Auto .
artikel nomen verb präposition fürwort adjektiv nomen punkt
Diese Folge von Token übergibt der Lexer dann zur weiteren Verarbeitung an den
Parser.
2.2.2 Token
Token sind syntaktische Elementarbausteine [WH09, S. 58], die in verschiedene
Klassen eingeteilt werden können. Sie bestehen aus einem Namen sowie einem
optionalen Attributwert. Der Name ist ein selbstbestimmtes Symbol, das vom Parser
weiterverarbeitet wird. Der Attributwert kann, wie z. B. bei Operatoren, die bereits
durch ihren Namen, z. B. mult_op, eindeutig definiert sind, leer sein oder, wie bei
Bezeichnern (ID), einen Zeiger enthalten, der auf einen entsprechenden Eintrag in der
Symboltabelle verweist. Diese Einträge sind wichtig, da ansonsten der Compiler in
späteren Phasen beispielsweise nicht entscheiden kann, ob es sich bei dem Token op um
ein „+“ oder ein „-“ handelt.
Tokenklassen können beliebig definiert werden und folgen keiner eindeutigen
Vorschrift. Ein Großteil der Programmiersprachen jedoch umfasst die in Tabelle 1
gezeigten Klassen [ALSU08, S. 137].
Token Beispiel Beschreibung
id abcd, Dipl.-Ing., E150d Buchstabe, auf den Buchstaben/Ziffern folgen
num 3, 26.587, 0 alle Zahlen
comp , =, !=, = alle Vergleichssymbole
op +, -, /, * die Grundoperatoren
saz (, ), ;, ,, … andere Satzzeichen (Klammern, Semikolon etc.)
if if das Wort if
else else das Wort else
literal „ Ausgabe“ alles, was in Anführungszeichen steht
Tabelle 1: Typische Tokenklassen
Neben diesen Klassen existiert außerdem für jedes Schlüsselwort, z. B. begin oder
end ein eigenes Token. Hierbei sind das Muster und der Tokenname gleich.
6

Kapitel 2: Lexikalische Analyse
2.2.3 Reguläre Ausdrücke
Reguläre Ausdrücke bilden die Basis für die Beschreibung der zu erkennenden Muster
im Eingabestrom des automatischen Scanners der lexikalischen Analyse und sind daher
ein wesentlicher Bestandteil des Compilerbaus. Das folgende Beispiel zeigt den
generellen Aufbau regulärer Ausdrücke:
( `+` + `-`) ? (0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 ) + (, (0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 +
8 + 9 ) + )?
Mit Hilfe dieses regulären Ausdrucks soll die Darstellung einer Kommazahl
aufgegriffen werden. Zunächst ist zu erkennen, dass zusammengehörige Abschnitte mit
einer Klammer gebunden werden. Die verschiedenen Ausdruckteile werden ohne
Zeichen aneinander gehängt. Somit bildet der gesamte Ausdruck die Konkatenation der
einzelnen Stücke [VW06, S. 64]. Das große Pluszeichen ermöglicht eine Auswahl
zwischen den Komponenten und definiert somit die vereinigte Menge der
Komponenten. Ein Synonym für das „+“ bietet der senkrecht Strich „|“. Um
festzulegen, wie oft ein Teil des regulären Ausdrucks wiederholt wird, d. h. wie viele
Instanzen gebildet werden, gibt es die Zeichen „?“, „*“ und „ + “. Dabei steht das
Fragezeichen, wie z. B. bei (+ | -) ?, für keine oder eine einzige Wiederholung. In einer
Kommazahl sollen natürlich nicht beliebig viele Minuszeichen auftauchen, sondern
höchstens eins zu Beginn. Eine weitere Darstellungsmöglichkeit für dieses Problem
wäre die Schreibweise (+ | - | ε). Das Fragezeichen fällt in diesem Fall weg, da für
„keine Wiederholung“ das leere Wort ε eingesetzt wurde. Das Pluszeichen steht für eine
oder mehrere Instanzen des regulären Ausdrucks. Es soll nun also im mittleren Teil des
Beispiels auf jeden Fall mindestens eine Ziffer abgebildet werden. Die dritte
Möglichkeit, der Stern, bildet beliebig viele Wiederholungen ab, d. h. also auch keine
ist möglich.
Formal wird ein regulärer Ausdruck wie folgt definiert [VW06, S. 65]:
Sei ∑ ein Alphabet, d. h. eine nicht leere, endliche Menge von Zeichen bzw.
Zeichenreihen, die total geordnet ist.
1. Ø ist ein regulärer Ausdruck und bezeichnet die leere Menge.
2. ε ist ein regulärer Ausdruck und bezeichnet das leere Wort, d. h. die Menge {ε}.
3. a ist ein regulärer Ausdruck und bezeichnet die Menge {a}.
7

Kapitel 2: Lexikalische Analyse
Per Induktion sind nun auch nachfolgende Ausdrücke definiert [Sc08, S.28 f]:
Seien a und b reguläre Ausdrücke, die die Mengen A und B beschreiben, dann
a) ist (a + b) bzw. (a | b) ein regulärer Ausdruck und bezeichnet die Menge A B
(Vereinigung).
b) ist (ab) ein regulärer Ausdruck und bezeichnet die Menge AB (Konkatenation)
c) ist (a*) ein regulärer Ausdruck und bezeichnet die Menge A* (Kleen’sche
Hülle).
d) Außerdem können weitere Klammern um die Ausdrücke gesetzt werden, ohne
dass sich die zu den Ausdrücken gehörige Sprache ändert. Eine
Klammereinsparung durch definierte Prioritäten der einzelnen Zeichen ist
jedoch für eine bessere Lesbarkeit von Vorteil.
Reguläre Sprachen [HJMJ02, S. 98] sind die Sprachen, die sich mit Hilfe regulärer
Ausdrücke beschreiben lassen. Um regulären Ausdrücken beispielsweise
verständlichere Namen zu geben, lassen sich reguläre Definitionen bilden [ALSU08,
S. 149]. Sie werden in der Form
Definition d → regulärer Ausdruck a (wobei a ∊ ∑),
also beispielsweise
ziffer → (0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 )
gebildet. Die Definition d ist ein neues Symbol, welches nicht im Alphabet ∑ enthalten
ist. Reguläre Definitionen sind hilfreich, um Rekursionen zu vermeiden und um die
Lesbarkeit der Ausdrücke zu verbessern.
2.2.4 Endliche Automaten
Aus dem im vorigen Kapitel gebildeten regulären Ausdrücken können nun
Übergangsdiagramme erstellt werden. Ein Übergangsdiagramm ist die grafische
Darstellung eines endlichen Automaten [VW06, Kap. 2], der aus Zuständen und
Übergängen zwischen diesen gebildet wird [HMJ02, S. 54]. Für den regulären
Ausdruck der Kommazahl aus dem Beispiel würde das Übergangsdiagramm wie folgt
aussehen:
8

Kapitel 2: Lexikalische Analyse
Abbildung 4: Endlicher Automat für Kommazahl
Zustände werden durch Kreise definiert, wobei der Anfangszustand mit einem Pfeil
ohne Quelle gekennzeichnet wird. Ein möglicher Endzustand wird durch einen
Doppelkreis abgebildet [ALSU08, S. 158]. Wie dieses einfache Beispiel zeigt, sind
durchaus mehrere Endzustände erlaubt. Die Übergänge bzw. Kanten zwischen den
Zuständen werden durch Pfeile symbolisiert. Als Beschriftung tragen sie das
eingelesene Zeichen der Eingabe. Anstatt mehrere Pfeile mit unterschiedlichen
Beschriftungen zwischen zwei Zuständen zu ziehen, werden alle Zeichen, getrennt
durch ein Komma, auf einer Kante angeordnet.
Formal wird ein endlicher Automat durch ein Tupel [Sc08, S. 19] definiert.
EA = (Q, ∑, δ, qo,F)
Q: endliche Menge von Zuständen hier: q0, q1, q2, q3 und q4
∑: endliche Menge von Eingabesymbolen hier: +. -, ∊, ziffer und ,
δ: Q × ∑ → Q Übergangsfunktion Menge von Regeln, durch die die
Übergänge abgebildet werden
qo ∊ Q: Startzustand
F Q: Endzustand hier: q2 und q4
Eine eingegebene Zeichenreihe bzw. ein regulärer Ausdruck wird von einem endlichen
Automaten akzeptiert, wenn der Automat einen Endzustand erreicht. Die Menge aller
akzeptierten Worte heißt dann reguläre bzw. akzeptierte Sprache.
Übergangsdiagramme sind nur eine Darstellungsform für endliche Automaten. Neben
dieser und der in der Definition gesehenen Mengen- bzw. Tupelschreibweise, gibt es
noch die Darstellung in Übergangstabellen [ALSU08, S. 179]. In der Tabelle
repräsentieren die Zeilen die Zustände und die Spalten die eingegebenen Zeichen. In der
Tabellenmitte wird derjenige Zustand eingetragen, der vom Zustand durch Eingabe des
9

Kapitel 2: Lexikalische Analyse
Zeichens erreicht wird. Diese Darstellungsform ist übersichtlich und gesuchte
Übergänge lassen sich leicht finden. Allerdings verbraucht sie viel unnötigen Platz, da
in der Regel die meisten Tabellenfelder ungenutzt bleiben.
Bisher wurde nur der deterministische endliche Automat (EA) betrachtet. Ein
nichtdeterministischer endlicher Automat (NEA) unterscheidet sich von einem EA
dadurch, dass, wie in Abbildung 5 gezeigt, aus einem Zustand mehrere Kanten mit der
gleichen Beschriftung in verschiedene Zustände laufen können [VW06, S. 27].
Abbildung 5: Nichtdeterministischer endlicher Automat
Jeder NEA lässt sich mit dem Verfahren der Potenzmengenkonstruktion in einen EA
umwandeln. Die Idee dieses Verfahrens ist, dass der zu konstruierende EA die Zustände
verwendet, in denen sich der NEA befinden könnte. Die auf diese Weise erstellte
Zustandsmenge des EA ist somit ein Teil der Potenzmenge aus den NEA-Zuständen.
Es ist leicht ersichtlich, dass ein EA auf Grund seiner Kürze und Eindeutigkeit schneller
ist. Allerdings wird in den meisten Fällen der erste Entwurf ein NEA sein, der
umgewandelt werden muss. Die Kosten für die Umwandlung lohnen sich jedoch im Fall
der lexikalischen Analyse, da der erstellte Automat durch die Eingabestücke mehrfach
genutzt wird [ALSU08, S. 197 ff].
2.2.5 Pattern-Matching / Tokenerkennung
Die Hauptaufgabe der lexikalischen Analyse ist die Mustererkennung im eingelesenen
Quellprogramm und die Zuweisung von Token. Dieses Vorgehen kann in folgende
Teile gegliedert werden.
1. Ausblenden bedeutungsloser Zeichen, u. a. Stopworteliminierung
2. Worterkennung
3. Kodieren der Symbole
10

Kapitel 2: Lexikalische Analyse
Zunächst werden nach dem Einlesen die für eine einfachere Analyse bedeutungslosen
Zeichen, wie z. B. Leerzeichen und Wörter, die keinen Sinn für die Analyse machen,
herausgefiltert und eliminiert [Kl99]. In einigen Fällen wird für diese Aufgabe ein
separater Screener genutzt.
Voraussetzung für die eigentliche Analysephase sind vordefinierte reguläre Ausdrücke
und ihnen zugeordnete Token, damit die erkannten Lexeme hiermit verglichen werden
können.
In der Phase der Worterkennung sollen nun Muster bzw. Lexeme im Eingabetext
gefunden werden (Pattern-Matching). Um eine Eingabe zu prüfen, kann diese von
einem durch reguläre Ausdrücke definierten Übergangsdiagramm gelesen werden.
Erreicht die Eingabe einen Endzustand, d. h. wird sie akzeptiert, ist ein Lexem gefunden
[ALSU08, S. 204]. In einem Automaten, wie in Abbildung 6 gezeigt, kann das Lexem
„begin“ überprüft werden.
Abbildung 6: EA für das Lexem "begin"
Stimmt die Eingabe mit dem Lexem „begin“ überein, erreicht der Automat den
Endzustand und „begin“ wurde erkannt. Die Ausgabe würde nun return (BEGIN);
lauten. Damit wäre auch direkt das Token BEGIN zugewiesen. Würde das eingegebene
Wort beispielsweise „begi“ lauten, würde der Automat nicht den Zustand q5 erreichen,
sondern einen Bezeichner identifizieren und als Token ID ausgeben.
Während der Eingabe kann es zu Problemen der Mehrdeutigkeit kommen. Es passen
mehrere Muster und es muss entschieden werden, welches genommen wird.
Beispielsweise kann die Zeichenfolge „< =“ auftauchen, die entweder als zwei einzelne
Zeichen oder als ein Symbol interpretiert werden kann. Die lexikalische Analyse bietet
für dieses Problem zwei Lösungsansätze. Im ersten Ansatz werden die eingegeben
Zeichen so lang gelesen, bis das nächste Zeichen zu keinem Lexem mehr passt. Es wird
also das längste, mögliche Muster (longest match) ausgewählt [LMB92, S. 34].
11

Kapitel 2: Lexikalische Analyse
Einen zweiten Lösungsansatz bietet die Symboltabelle. Üblicherweise werden, wie in
Abbildung 7, bis Index 9 die sogenannten reservierten Schlüsselwörter verwaltet
[ALSU08, S. 160]. Diese Wörter sind, wie z. B. BEGIN, Wörter, die in der
Programmiersprache eine bestimmte Rolle spielen und daher geschützt werden müssen.
Index
1
2
3
4
.
.
.
9
10
11
12
const
var
begin
end
.
.
.
odd
abcd
Dipl.-Ing.
E150d
Schlüsselwörter
Bezeichner
Abbildung 7: Symboltabelle mit reservierten Schlüsselwörtern
Taucht nun das Problem der Mehrdeutigkeit auf, wird das Wort erkannt, welches als
erstes in der Symboltabelle steht. Findet die lexikalische Analyse z. Β. das Muster
„beginnen“, wird sie auf Grund des zweiten Lösungsansatzes das Lexem BEGIN sowie
einen Bezeichner „nen“ identifizieren. Als Ergebnis werden die beiden Token BEGIN
und ID ausgegeben.
2.2.6 Eingabepuffer
Das Einlesen der Eingabezeichen wird dadurch erschwert, dass oft über das nächste
Lexem hinausgeblickt werden muss (Lookahead). Um das Muster zu identifizieren,
müssen noch ein oder mehrere zusätzliche Zeichen gelesen werden. Der Eingabepuffer
soll diese Problem mindern und den Einlesevorgang beschleunigen, indem nicht jedes
Zeichen einzeln aufgerufen werden muss.
Aufgebaut ist solch ein Eingabepuffer meist durch zwei separate Puffer der Größe N,
wie ihn Abbildung 8 zeigt [ALSU08, S. 141]. Die Größe entspricht hierbei
12

Kapitel 2: Lexikalische Analyse
üblicherweise einem Festplattenblock. Jeder der Puffer kann somit bis zu N Zeichen
einlesen. Sollte die Eingabe weniger Zeichen haben, wird das Ende durch eof
gekennzeichnet. Normalerweise genügen N Pufferplätze, da Lexeme in modernen
Sprachen kurz sind [ALSU08, S. 142] und ein Lookahead von ein bis zwei Zeichen
genügt. Sollte ein Muster dennoch länger sein, wird die Zeichenkette in mehrere Zeilen
unterteilt. Die Zeilen werden dann als Konkatenation behandelt und mit einem „+“
verbunden.
Umf = 2 * Pi * Rad eof
lexemeBegin
forward
Abbildung 8: Eingabepuffer
Quelle: Vgl. [ALSU08, S. 141]
Für den Eingabepuffer gibt es zwei Zeiger, welche die Mustersuche kontrollieren. Der
Zeiger lexemeBegin markiert den Anfang des aktuellen Lexems, während forward
jeweils ein Zeichen vorrückt, bis er eine Musterübereinstimmung gefunden hat. Erreicht
forward das Ende des einen Puffers, wird der andere gefüllt und die Suche wird dort
fortgesetzt.
2.3 Probleme
Einige Probleme, wie z. B. Behandlung von Mehrdeutigkeiten, Zeichensetzungsfehler
im Programmtext oder Beschleunigung des Einleseprozesses, kann die die lexikalische
Analyse lösen.
Ein großes Problem, auf das die lexikalische Analyse jedoch stößt, betrifft die
Rechtschreibung [ALSU08, S. 139]. Wenn der Nutzer einen Quelltext mit falsch
geschriebenem Text eingibt oder bei der Definition der regulären Ausdrücke einen
unbeabsichtigten Fehler macht, kann dieser nicht erkannt werden. Beispielsweise würde
das Wort „begni“ im Analyseprozess als Bezeichner identifiziert und bekäme anstatt
BEGIN das Token ID zugewiesen. Der Lexer würde gegebenenfalls sogar abstürzen, da
er kein passendes Präfix eines Musters findet.
13

Kapitel 2: Lexikalische Analyse
Da in der Praxis die meisten Fehler nur ein Zeichen betreffen, ist es empfehlenswert zu
schauen, ob sich die Eingabe durch einzelne Umformungen in ein gültiges Lexem
umwandeln lässt. Dies geschieht mit Hilfe von Recovery-Aktionen, z. B. dem Panic
Mode Recovery [Kl99]. Es werden nacheinander die eingegebenen Zeichen gelöscht,
bis ein bekanntes, einwandfreies Token gefunden wird. Weitere Techniken zur
Fehlerbehebung sind das Löschen eines überflüssigen Zeichens, das Einfügen eines
fehlenden oder das Ersetzen eines Zeichens durch ein anderes. Außerdem können zwei
benachbarte Zeichen vertauscht werden, damit Rechtschreibfehler wie in „begni“
behoben werden [ALSU08, S. 140]. Die Gefahr bei diesen Techniken besteht darin,
dass erneut das Problem der Mehrdeutigkeit entsteht. So könnte in diesem Fall sowohl
BEGIN als auch BEGNII ein vordefiniertes, einwandfreies Token sein.
2.4 Aufwand und Optimierungsmöglichkeiten
Für eine effiziente Umsetzung der lexikalischen Analyse ist eine Aufwandsbetrachtung
unumgänglich. Bisher gibt es kaum Studien, die den Aufwand bzw. die Kosten der
lexikalischen Analyse genau bestimmen. Da jedoch während dieser Phase jedes
Eingabezeichen einzeln geprüft werden muss, ist sie sehr teuer und es wird geschätzt,
dass ca. 50% der gesamten Ressourcen der Kompilierung für die lexikalische Analyse
verwendet werden [Kl99].
Der genaue Aufwand hängt jedoch von unterschiedlichen Faktoren ab. Jede
Programmiersprache handhabt beispielsweise den Einsatz von Leerzeichen für die
Lesbarkeit oder Verwendung von Schlüsselwörtern anders. So braucht ein Scanner, der
in Fortran verfasst wurde, aus diesen Gründen wesentlich mehr Lookahead als ein in
Pascal programmierter. Ein weiterer Aspekt, der bei der Aufwandsschätzung betrachtet
werden sollte, ist die Länge der Eingabe. Je länger der Eingabestrom, desto länger läuft
natürlich auch die gesamte Analyse. Hierbei kommt es nicht auf die Anzahl oder
Komplexität der zu erkennenden Regeln an. Diese spielen lediglich für die Größe des
lex-Programmes eine Rolle. Eine Ausnahme jedoch sind die Regeln, welche einen
Lookahead voraussetzen. Durch diesen ergibt sich offensichtlich ein doppelter
Aufwand, da hier im Eingabestrom im Voraus gelesen werden muss, um ein aktuelles
Lexem zu bestimmen und dann erneut, um das nächste Muster zu finden.
14

Kapitel 3: Generierung eines Scanners
Es muss also bei der Generierung eines Lexers für die lexikalische Analyse besonderer
Wert auf die Operationen, die einzelne Zeichen betreffen, gelegt werden, damit vor
allem der zeitaufwändige Einleseprozess beschleunigt wird.
Im Folgenden sollen kurz drei mögliche Optimierungsansätze vorgestellt werden,
welche das Pattern Matching auf Basis regulärer Ausdrücke verbessern können
[ALSU08, S. 209]. Der erste Algorithmus hilft beim Aufbau der Automaten aus den
regulären Ausdrücken direkt einen EA zu erstellen, ohne den Umweg über einen NEA.
Dadurch werden zusätzliche Kosten vermieden. Außerdem kann ein auf diese Weise
erstellter Automat auch gegebenenfalls weniger Zustände aufweisen. Ein zweiter
Optimierungsansatz beschäftigt sich mit der Minimierung der Anzahl der Zustände.
Durch ein Zusammenfassen identischer Zustände wird die Mustererkennung effizienter
und läuft in der Zeit O(n log n) ab, wobei n die Anzahl der Zustände markiert. Im
letzten Algorithmus soll die Mustererkennung über Übergangstabellen erfolgen. Dazu
müssen diese kompakter aufgebaut werden, als die Platz verbrauchende, ursprüngliche
Schreibweise.
3 Generierung eines Scanners
3.1 Anforderungen an einen Scanner
Bei der Entwicklung und Implementierung eines Scanners müssen zunächst einige
Fragen bezüglich der Anforderungen geklärt werden. Die Implementierung des
Scanners entscheidet später, in welcher Form die Eingabedaten für den Compiler
vorliegen müssen, damit sie verarbeitet werden können.
In der Designphase muss sich der Nutzer auch über einfache Fragestellungen, z. B.
„Was ist ein Wort für meinen Compiler?“, Gedanken machen. Ein Wort ist zunächst
einmal eine Zeichenkette beliebiger Länge. Jedoch muss festgelegt werden, ob „BeGin“
das gleiche wie „BEGIN“ oder „begin“ ist. Soll das Programm Groß- und
Kleinschreibung unterscheiden und wenn ja auf welche Weise? Geklärt werden muss
auch, ob das Wort „Beginnen“ eine ID darstellt oder ob es das Schlüsselwort BEGIN
mit einem folgenenden Bezeichner NEN ist.
15

Kapitel 3: Generierung eines Scanners
Eine andere Fragestellung betrifft die Darstellung der Zahlen. Sind diese grundsätzlich
erlaubt? Was passiert mit Wörtern, die sowohl aus Zahlen, als auch aus Buchstaben
bestehen (z. B. Farbstoff E150d)? Außerdem müssen Wörter mit Bindestrichen und
weitere Zeichensetzungen berücksichtigt werden.
Diese Probleme der Sprachbeschreibung sind nicht schwer zu lösen bzw. es existieren
bereits Lösungen, wie z. B. die Methode der reservierten Schlüsselwörter. Dennoch
sollte sich der Nutzer vor Beginn der Implementierung diese Probleme bewusst machen.
Ansonsten kann es zur Laufzeit des Scanners Probleme geben, wenn der Scanner ein
eingelesenes Zeichen einer Tokenklasse nicht erkennen kann und den gesamten
Vorgang der lexikalischen Analyse unterbricht.
Eine weitere Anforderung an den Scanner muss eine effiziente Durchführung der
lexikalischen Analyse sein. Effizienz ist in allen Bereichen der Programmierung nahezu
unumgänglich und sollte auch hier nicht vernachlässigt werden. Eine effiziente
lexikalische Analyse dient dem kompletten Prozess des Compilers. Je schneller der
Scanner ein klares und eindeutiges Ergebnis ohne Fehler für die Weiterverarbeitung
liefert, desto schneller kann auch von der Syntaxanalyse und den folgenden Phasen ein
Ergebnis erwartet werden. Besonders im parallelen Verarbeitungsprozess des scan on
demand ist eine zügige Bearbeitung erforderlich, um einen effizienten Ablauf zu
gewährleisten.
3.2 Manuelle Generierung
Die erste intuitive Erstellung eines Scanners kann per Hand erfolgen. Dazu wird im
ersten Schritt ein Übergangsdiagramm erstellt, welches die Struktur der Symbole des
Quellprogramms beschreibt.
Im nächsten Schritt wird zu diesem Diagramm ein Programm erstellt, das die Symbole /
Token erkennt. Dazu müssen die Zustände nummeriert und jeweils durch ein Stück
Code wiedergegeben werden. Eine Variable state nimmt während des Durchlaufs die
Nummer des gerade aktuellen Zustands auf.
Um nun den erstellten Code des Übergangsdiagramms in einen Scanner zu überführen,
gibt es drei verschiedene Möglichkeiten [ALSU08, S. 164] die eingelesenen Zeichen
einem Token zuzuordnen. Die erste Möglichkeit besteht darin, die einzelnen
16

Kapitel 3: Generierung eines Scanners
Übergangsdiagramme nacheinander auszuprobieren, bis das Muster mit dem Diagramm
eines Token übereinstimmt. Da dieses Verfahren allerdings äußerst lang dauern würde,
sieht die zweite Option ein paralleles Testen der Übergangsdiagramme vor. Es wird
immer das nächste Zeichen der Eingabe an alle Diagramme übermittelt und so das
längste, passende Token ermittelt. Die effizienteste und damit am meisten genutzte
Variante zielt auf ein einziges, zusammengefasstes Übergangsdiagramm ab. Genau wie
bei der zweiten Möglichkeit wird die Eingabe solang gelesen, bis es keinen nächsten
Zustand gibt und das längste, passende Muster ermittelt wurde.
Die Implementierung eines Scanners per Hand kann, wenn sie fehlerfrei erfolgt, einen
effizienten Scanner für ein kleines Problem, beispielsweise einen einfachen
Taschenrechner, ergeben. Allerdings können zum einen leichte Änderungen hin zu
einem anderen Problem äußerst umfangreich und langwierig sein. Zum anderen ist eine
Fehlerfreiheit bei manueller Implementierung in den meisten Fällen nicht gegeben und
eine Identifizierung und Auffindung auftretender Probleme ist äußerst schwierig.
3.3 Der Scannergenerator lex
3.3.1 Einführung in lex und Darstellung seiner Vorteile
In den 70er Jahren wurde der Scannergenerator lex als Ergänzung zum Parser-Generator
yacc entwickelt. Lex ist ein Unix-Standardwerkzeug [VW06, S.79] und ist selbst
vergleichbar mit einem Compiler, der automatisch einen Scanner erzeugt und somit lex-
Programme in ein C-Programm für die lexikalische Analyse umwandelt. Im Gegensatz
zur manuellen Implementierung ermöglicht dieser Generator eine kürzere
Entwicklungszeit, da die Eingabezeichen nicht mühsam per Hand gesucht und extrahiert
werden müssen. Er ist somit besonders für komplizierte und komplexe Probleme
geeignet. Außerdem ist durch den immer gleichen Aufbau eine bessere Lesbarkeit
gegeben und auch Änderungen lassen sich leichter durchführen. Nutzer von lex
benötigen keine umfangreichen Programmier- und Pattern-Matching-Kenntnisse,
sondern es genügen Grundkenntnisse der theoretischen Informatik, insbesondere der
regulären Ausdrücke [LS06].
17

Kapitel 3: Generierung eines Scanners
3.3.2 Arbeitsweise eines lex-Generators
Als Eingabe akzeptiert der Scannergenerator lex ein sogenanntes lex-Programm. Ein
lex-Programm ist eine Tabelle mit regulären Ausdrücken, die den zu erstellenden
Scanner bzw. Lexer beschreibt [ALSU08, S. 171]. Außerdem ist in der Tabelle der
dazugehörige Programmteil enthalten, welcher die zu treffenden Aktionen repräsentiert
und üblicherweise in C verfasst ist. Möglich ist aber auch ein Programmteil in der
Programmiersprache Ratfor aus dem Jahr 1976, zu der automatische Übersetzungen in
Fotran angeboten werden [He03, S. 25]. Das Programm besteht aus drei Teilen, welche
in Kapitel 3.3.3 näher beschrieben sind.
Wie in Abbildung 9 [Be02] gezeigt, wird aus dem lex-Programm, hier lex.l genannt,
mit Hilfe des Lex-Compilers die Funktion yylex() konstruiert und in die Datei
lex.yy.c überführt. Im Hintergrund dieses Compilers werden, ähnlich wie bei der
manuellen Generierung, aus dem eingegebenen lex-Programm ein Übergangsdiagramm
bzw. der dazugehörige Code erzeugt. Die Datei lex.yy.c kann dann dieses
Übergangsdiagramm simulieren.
lex-Programm
lex.l
Lex-
Compiler
lex.yy.c
lex.yy.c C-Compiler a.out
Eingabezeichen a.out
Folge von Token
Abbildung 9: Lexer-Erstellung mit Lex
Im nächsten Schritt wird die Datei lex.yy.c mit Hilfe des C-Compilers zu a.out
kompiliert. Bei Verwendung der C-Funktion a.out wird eine Integerzahl
zurückgegeben. Diese Zahl stellt dann einen Code für ein mögliches Token dar.
Zusammenfassend müssen also für die Erstellung eines Lexers mit lex ein lex-
Programm, welches insbesondere aus der Definition von Symbolen mittels regulärer
Ausdrücke besteht, und ein Eingabestrom vorhanden sein. Der erstellte Scanner kann
nun Lexeme erkennen und Folgen von Token ausgeben. Gleichzeitig kann er die im C-
Teil des lex-Programmes verknüpften Aktionen ausführen.
18

Kapitel 3: Generierung eines Scanners
Der Lexer kann während seines Aufrufs Attributwerte, wie z. B. Zeiger auf die
Symboltabelle oder weiteren Code, in der globalen Variable yylval ablegen. Während
der Syntaxanalyse kann der Parser diese Informationen aus der Variablen beziehen.
3.3.3 Struktur eines lex-Programmes
Ein lex-Programm ist, wie in Abbildung 10 gezeigt, aus einem Deklarationsteil, den
Übersetzungsregeln und den Hilfsfunktionen [LS06] aufgebaut.
%{
Deklaration
%}
%%
Übersetzungsregeln
%%
Hilfsfunktionen
Abbildung 10: lex-Spezifikation
Der Deklarations- bzw. Definitionsteil ist optional und enthält C-Code [Vö96]. Dieser
besteht aus Optionen, Deklarationen von Variablen, manifesten Konstanten, welche
z. B. mit Hilfe von #define erzeugt wurden, und regulären Definitionen. Da dieser
Teil zwischen den Zeichen %{ … %} steht, wird er, laut lex-Definition, unverändert in
den erzeugten Scanner übernommen.
Der Hauptteil des lex-Programmes besteht aus den Übersetzungsregeln. Dies ist eine
Tabelle mit Mustern und Aktionen in der Form Muster{Aktion}. Jedes Muster stellt
dabei einen regulären Ausdruck dar, der reguläre Definitionen des
Deklarationsabschnitts nutzt. Es kann eine Aktion aufrufen, die durch eine einzelne oder
eine Folge von C-Anweisung deklariert ist. Anstelle einer C-Anweisung kann auch das
Zeichen „|“ stehen, welches besagt, dass für dieses Muster die gleiche Aktion wie für
das folgende Muster ausgeführt wird. Sollte ein gelesenes Zeichen nicht in ein Muster
passen, wird es wie %{ … %} unverändert in die Ausgabe kopiert.
Der dritte Teil, welcher die Hilfsfunktionen enthält, ist wieder optional. Üblicherweise
beinhaltet er lokale Funktionen, die durch die Übersetzungsregeln genutzt und in
19

Kapitel 3: Generierung eines Scanners
Aktionen eingesetzt werden. Auch dieser Teil kann Textstücke enthalten, die
unverändert übernommen werden.
Zur Veranschaulichung des Programmaufbaus soll das Beispiel eines Taschenrechners
dienen. Als Eingabezeichen gibt es die Zahlen von 0 bis 9 sowie die Zeichen +, -, / und
*. Aus einem einfachen C-Programm [HE03, S. 8] dieser Art ergibt sich für die
lexikalische Analyse mit Hilfe von lex folgender Code:
%{
#include
#include „global.h“
int tokenwert = NICHTS; /*Programmglobale Variable, der ggfs.
Zahlenwert zugewisen wird*/
int zeilennr = 1; /*Programmglobale Variable, enthaelt
immer Nr der aktuellen Eingabezeile*/
%}
%%
[ \t]+ /*Leer- und Tabzeichen ueberlesen*/
\n {return (ZEILENENDE);}
[0-9]+{tokenwert = strtol(yytext,NULL,10); return(ZAHL)}
/*strtol wandelt den String aus
yytext in eine Zahl um und weist sie
tokenwert zu'/
"+" {return (PLUS);}
"-" {return (MINUS);}
"*" {return (MULT);}
"/" {return (DIV);}
%%
Dieses Beispiel enthält einen Deklarationsteil mit C-Definitionen und im Anschluss die
Übersetzungsregeln, die definieren, welches Token (ZEILENENDE, ZAHL, PLUS,
MINUS, MULT, DIV) ausgegeben wird.
3.4 Weitere Scannergeneratoren
Neben dem Ur-Scannergenerator lex gibt es noch zahlreiche weitere
Scannergeneratoren.
Der am weitesten verbreitete und frei erhältliche Generator ist Flex [Pa95]. Er ist der
Nachfolger von lex und ermöglicht nun auch eine Nutzung unter Windows. Die
Implementierung ist schneller und effizienter geworden. Genau wie bei lex werden
20

Kapitel 4: Zusammenfassung und Ausblick
reguläre Ausdrücke verarbeitet und das Ergebnis ist ein tabellengesteuerter Automat in
C. Außerdem bietet Flex wieder eine Schnittstelle zum Parser-Generator von yacc.
Ähnlich zu Flex ist der Scannergenerator Rex des GMD – Forschungszentrum
Informationstechnik GmbH Karlsruhe. Auch er bietet programmierbare
Zustandsübergänge und eine Schnittstelle zu yacc. Die Implementierung ist ebenso
tabellengesteuert in C und schneller als bei lex. Es gibt jedoch auch eine
Implementierungsmöglichkeit mit Modula-2.
Der Scannergenerator GLA der University of Colorado hingegen beruht auf einer etwas
anderen Implementierung. GLA arbeitet mit Komponenten der Entwicklungsumgebung
Eli zusammen und liefert als Ergebnis einen direkt programmierten Automaten in C.
Weitere Scannergeneratoren sind u. a. SableCC, der ein Java-Ergebnis liefert, ALEX,
COCO und der Scanner-, Parser- und Compilergenerator VCC [WH09, S. 121].
4 Zusammenfassung und Ausblick
Als erste Phase bei der Übersetzung von Quellprogrammen durch einen Compiler ist die
lexikalische Analyse einer der wichtigsten Abschnitte. Ihre erste Aufgabe ist das
Einlesen des Quelltextes. Anschließend werden mit Hilfe eines Lexers Muster erkannt
und diese durch Token ersetzt. Die lexikalische Analyse trägt somit zu einer
nennenswerten Erleichterung der Kompilierung bei. Um den gesamten Prozess dieser
Phase für einen Nutzer so leicht wie möglich zu machen, werden die zu erkennenden
Muster mit Hilfe regulärer Ausdrücke definiert. Da keine umfangreichen
Programmierkenntnisse erforderlich sind, sind auch Scannergeneratoren wie lex sehr
attraktiv. Sie erleichtern den Vorgang der lexikalischen Analyse erheblich.
An der Vielzahl der bereits existierenden Generatoren kann man erkennen, dass die
Entwicklung noch kein Ende hat. Auch wenn der Compilerbau mit fast 70 Jahren eines
der ältesten Gebiete der praktischen Informatik ist, kann es ständig Neuerungen und
Verbesserungen geben. Beispielsweise können Generatoren auf unterschiedliche
Programmiersprachen erweitert werden, um noch mehr Einsatzmöglichkeiten zu bieten.
Es werden daher beispielsweise so genannte Migrationscompiler entwickelt. Sie helfen,
große Projekte, welche in wenig bekannten Programmiersprachen verfasst sind, auf
moderne Programmiersprachen zu migrieren. So wurde z. B. das Toyota-
21

Kapitel 4: Zusammenfassung und Ausblick
Händlersystem, welches auf ROSI-SQL beruhte, mit Hilfe eines solchen Compilers auf
C++ umgestellt, um die hohen Investitionskosten in dieses Projekt nicht zu verschenken
[BJ94]. Außerdem ist die Effizienzverbesserung ein wichtiger Faktor. Zukünftig müssen
alle Geräte noch schneller und noch kleiner werden. So sind Techniken, wie die
Übergangstabellenverkleinerung, wichtige Ansatzpunkte. Die Methoden werden immer
ausgefeilter, um eine möglichst hohe Effizienz zu bieten. Gleichzeitig sollen aber auch
die Kosten reduziert werden.
Dadurch, dass es aktuell und auch in der Zukunft auf anderen Gebieten der Forschung,
wie z. B. der Größe und Kapazität von Speichermedien und Verbesserung der
Prozessoren, ständig neue Erkenntnisse gibt bzw. geben wird, kann der Compilerbau
ebenso fortschreiten und somit neue Techniken, auch für die lexikalische Analyse,
bieten.
22

Kapitel 5: Literaturverzeichnis
5 Literaturverzeichnis
[ALSU07] A. V. Aho, M. S. Lam, R. Sethi, J. D. Ulman: Compilers, Pearson, 2007.
[ALSU08] Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman: Compiler:
Prinzipien, Techniken und Werkzeuge, 2. Auflage, Pearson Studium, 2008.
[Be02] Peter Becker: Lexikalische Analyse und Parsing, http://www2.inf.fh-rheinsieg.de/~pbecke2m/textalgorithmen/lexanalyse.pdf,
2002.
[Br04] Jan Bredereke: Übersetzergenerierung mit lex & yacc,
http://www.informatik.uni-bremen.de/agbs/lehre/ss04/uegen/, 2004.
[BJ94] Peter Brückner, Wolfgang Jarosch: R2C–Migrationscompiler – Migration von
ROSI-SQL nach C++, http://www.bj-ig.de/compilerbau.html, 1994.
[He03] Helmut Herold: lex & yacc: Die Profitools zur lexikalischen und syntaktischen
Textanalyse, 3. Auflage, Addison-Wesley Verlag, 2003.
[HMJ02] John E. Hopcroft, Rajeev Motwani, Jeffrey D. Ullman: Einführung in die
Automatentheorie, Formale Sprachen und Komplexität, 2. Auflage, Pearson
Studium, 2002.
[Kl99] Frank Kleine: Lexikalische Analyse und Stoplisten,
http://talks.frankkleine.de/ir/, 1999.
[LMB92] John Levine, Tony Mason, Doug Brown: lex & yacc, 2. Auflage, O`Reilly,
1992.
[LS06] M. E. Lesk and E. Schmidt: Lex – A Lexical Analyzer Generator,
http://dinosaur.compilertools.net/lex/index.html, 2006.
[Pa95] Vern Paxson: Flex, version 2.5: A fast scanner generator,
http://dinosaur.compilertools.net/flex/index.html, 1995
[Sc08] Uwe Schöning: Theoretische Informatik – kurz gefasst, 5. Auflage, Spektrum
Akademischer Verlag, 2008.
[VW06] Gottfried Vossen, Kurt-Ulrich Witt: Grundkurs Theoretische Informatik,
3. Auflage, Vieweg+Teubner Verlag, 2006.
[Vö96] Reinhard Völler: Formale Sprachen und Compiler, http://users.informatik.hawhamburg.de/~voeller/fc/comp/comp.html,
1996.
[WH09] Christian Wagenknecht, Michael Hielscher: Formale Sprachen, abstrakte
Automaten und Compiler, Vieweg+Teubner Verlag, 2009.
[Wi02] Arnold Willemer: Compilerbau,
http://www.willemer.de/informatik/compiler/index.htm, 2002
[Wi08] Niklaus Wirth: Grundlagen und Techniken des Compilerbaus, 2. Auflage,
Oldenbourg Wissenschaftsverlag, 2008.
23