Zur Erinnerung: sowohl “1+2+3″ als auch “1+(” wären Zeichenfolgen, die der Lexer akzeptieren und ohne zu meckern zerkleinern würde. Das ist auch in Ordnung so, da die syntaktische Prüfung ohnehin eher Aufgabe des Parsers ist. Aber was genau gilt es denn dabei zu beachten?

“Syntaxfragen”

• Sind genau so viele öffnende wie schließende Klammern vorhanden und passen diese zusammen?
• Stimmt die Zahl der Parameter, mit der eine Funktion aufgerufen wird?
• Stimmen die Parametertypen, mit denen eine Funktion aufgerufen wird? (“+” arbeitet normalerweise nur auf Zahlen, der Punkt z.B. in PHP auf Strings, etc…)
• Befinden sich Operatoren an den richtigen Positionen? (Die Fakultät einer Zahl wird z.B. durch Anhängen eines Ausrufezeichens gekennzeichnet: “3!”)
• Darf eine Funktion geschachtelt vorkommen? (z.B. wäre “echo(echo(1))” eher sinnlos, wenn “echo” die Ausgabefunktion ist)
• Darf eine Funktion/ein Konstrukt in einer untergeordneten Umgebung vorkommen? (Das wäre z.B. der Fall, wenn man Funktionsdefinitionen innerhalb von Funktionsdefinitionen zulässt.)

Neben der Syntax gibt es noch weitere Punkte, die eine Programmier-/Scriptsprache ausmachen. Eine Auflistung findet man z.B. hier.

Einiges ist schon erledigt

Der im vorhergehenden Teil präsentierte Shunting-Yard-Algorithmus nimmt uns die Überprüfung der Klammern, sowie der Position der Parameter bereits ab. Des weiteren ist es unumgänglich zur Erstellung des Syntaxbaumes die Anzahl der Parameter zu kennen, die eine bestimmte Funktion benötigt. Wir können also unsere Liste auf die Hälfte kürzen.

Einiges noch nicht

Der Syntaxbaum selbst macht die Syntaxprüfung recht simpel. Aber zuerst müssen wir für jede Funktion, jeden Operator und jedes Terminalsymbol festlegen, welche syntaxktischen Eigenschaften es hat. Das wird letztlich mittels einer Klasse SyntaxDefinition realisiert werden, die die entsprechenden Daten kapselt.

Wichtig ist hierbei: wir betrachten all die genannten Datentypen als Funktionen, auch die Terminalsymbole. Jede Funktion hat einen Rückgabetyp und beliebig viele Parametertypvarianten. Eine “Zahl” wäre also eine Funktion mit dem Parametertyp “Zahl” und dem Rückgabetyp “Zahl”.

Eine beispielhafte Aufstellung für die Syntax einer Sprache wäre die folgende:

• Terminalsymbol Integer:
  • Eingabe: Integer
  • Rückgabe: Integer
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• Terminalsymbol String:
  • Eingabe: String
  • Rückgabe: String
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• Terminalsymbol Identifier:
  • Eingabe: Identifier
  • Rückgabe: Identifier
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• Funktion DefConstant:
  • Eingabe: (Identifier, Integer) oder (Identifier, String)
  • Rückgabe: keine
  • Verschachtelung nicht erlaubt
  • Unterordnung erlaubt
• Operator Plus:
  • Eingabe: (Integer, Integer)
  • Rückgabe: Integer
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• …

Es gibt aber auch Funktionen, deren Rückgabetyp erst zum Ausführungszeitpunkt feststeht. Bestes Beispiel ist hier die Auswertung von Variablen, die ja Werte verschiedenster Typen enthalten können.

Wie würde also nun die Überprüfung der Typkorrektheit und der Verschachtelung ablaufen? Wie bereits erwähnt nutzen wir hierfür den Syntaxbaum und testen jeden einzelnen Knoten unter Berücksichtigung der Kindknoten:

               operator : +
              /            \
        integer : 1     operator : *
                       /            \
                  integer : 2   function : echo
                                     |
                                constant : e

Für unseren Test entspräche das dem folgenden Baum (Notation: “Rückgabe / Verschachtelung erlaubt?”):

               integer / ja
              /            \
        integer / ja    integer / ja
                       /            \
                  integer / ja  void / nein
                                     |
                                runtime / ja

Die Wurzel (das Plus) erwartet zwei Parameter des Typs “integer”. Eine Überprüfung der Kindknoten zeigt, dass diese genau diesen Rückgabetyp besitzen – also alles in Ordnung , auch die Verschachtelung.
Betrachtet man den rechten Ast weiter, sieht man zwei Probleme: die Multiplikation benötigt zwei “integer”-Parameter, erhält aber “integer” und “void” (void ist der Ausdruck für “keine Rückgabe”); und die “echo”-Funktion kann nicht geschachtelt auftreten, befindet sich aber auf Ebene 2.

Einen dieser Fehler sollte der Parser letztlich ausgeben und abbrechen!

Einiges muss warten

Ob ein Ausdruck in einer untergeordneten Umgebung auftritt, kann ein reiner Parser nicht wissen. Man könnte ihm zwar diesbezügliche Informationen zukommen lassen (und sollte das auch, wenn man vorhat, einen Compiler o.Ä. zu schreiben), der einfachste Ort für diese Überprüfung ist jedoch die Auswertung. (Das ist auch scriptsprachentauglich.)

Was die Parametertypen angeht, die erst bei der Ausführung feststehen, kann man entweder mit regulären Ausdrücken arbeiten und mit deren Hilfe die Teilergebnisse untersuchen, bevor man die übergeordnete Funktion aufruft, oder man überlässt das ganz der jeweiligen Funktion selbst. Geschmacksache.

Spezielle Konstrukte

In jeder Sprache gibt es bestimmte Schlüsselwörter, die spezielle Konstrukte beschreiben/einleiten. Gemeint ist soetwas wie:

def a = 2

Der Shunting-Yard-Algorithmus kommt aber nur mit Operatoren oder mit Funktionen der Form “f(p1, p2, …)” klar.

Kein großes Problem?

Gut, das wäre jetzt kein großes Problem für das oben stehende Beispiel: man definiert “def” und “=” als Operatoren, wobei “def” ein Präfix-Operator mit genau einem Parameter ist und eine höhere Priorität als “=” hat. Der Operator “def” legt eine leere Variable mit dem übergebenen Namen an und liefert diesen Namen als Rückgabewert.
“=” wiederum ist ein Infix-Operator mit zwei Parametern, das die (existierende!) Variable des übergebenen Namens mit dem übergebenen Wert füllt.

Der Syntaxbaum für oben genannten Ausdruck wäre dann:

              operator : =
              /          \
     operator : def   integer : 2
             |
     identifier : a

Und schon hätten wir das  gewünschte Verhalten, allerdings auf Kosten der Übersichtlichkeit in der Implementierung, sowie eines sehr großen Freiraums in der Grammatik. Immerhin wäre so etwas dann auch erlaubt:

(((((def a))))) = 2
def b = def a

Ein Verhindern von Verschachtelungen ist hier nicht mehr möglich.

Bessere Lösung

Wir brauchen einen Mechanismus, der aus “def a = 2″ so etwas macht wie “def(a, 2)”, also einen regulären Funktionsaufruf. Es handelt sich hierbei um eine Mustererkennung auf Basis bereits gelesener Token, d.h. die eigentliche Umwandlung findet nach dem erstmaligen Einlesen der Eingabesequenz durch den Lexer statt:

keyword : def
identifier : a
operator : =
integer : 2

wird zu

function : def
open : (
identifier : a
comma : ,
integer : 2
close : )

In meinen Augen bietet sich hierfür wieder  der in Teil 1 unter Alternative 4 vorgestellte Algorithmus an, der z.B. mit einem Automaten arbeiten könnte, der die folgende Akzeptanzfunktion besitzt (Vorsicht: Pseudocode!):

private int tokenNumber = -1;
public bool accept(Token t)
{
    tokenNumber++;
    return
        (tokenNumber == 0 && "t ist vom Typ 'keyword' und hat den Wert 'def'") ||
        (tokenNumber == 1 && "t ist vom Typ 'identifier'") ||
        (tokenNumber == 2 && "t ist vom Typ 'operator' und hat den Wert '='") ||
        tokenNumber > 2;
}

Gleichzeitig müssten irgendwo die relevanten Token gesichert werden, damit die Umwandlung in eine Funktion später auch reibungslos vonstatten gehen kann.

Ich würde sagen, damit haben wir eine vernünftige Lösung gefunden.

Fazit

Wir können nun unseren Syntaxbaum auf syntaktische Merkmale hin untersuchen und spezielle Ausdrücke und Konstrukte berücksichtigen. Langsam sollten wir uns also an die Ausführung eines Ausdrucks machen.

Ein in diesem Artikel häufig verwendetes Wort war “Umgebung”. Es handelt sich dabei um den Speicher für Variablen, Funktionen, etc… Ohne diesen ist die Entwicklung einer Scriptsprache relativ witzlos, weswegen wir an genau dieser Stelle weitermachen werden.

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax

zahl        :    1
operator    :    +
zahl        :    3
operator    :    *
open        :    (
zahl        :    4
operator    :    -
zahl        :    2
close       :    )

Damit haben wir eine maschinenlesbare Repräsentation des gewünschten Ausdrucks – allerdings keine Garantie dafür, dass dieser syntaktisch korrekt ist. Ebensowenig kann eine Maschine, die diese Liste nun vorgelegt bekommt, “einfach mal so” den Wert des Ausdrucks berechnen, da ihr Informationen zur Auswertungsreihenfolge fehlen. (Wenn 1+3 zuerst berechnet wird, lautet das Ergebnis 8, wenn 3*(4-2) zuerst berechnet wird, lautet es 7.)

Wir brauchen also eine Darstellung unseres Ausdrucks, die bezüglich der Reihenfolge der Auswertung eindeutig ist und eine Maschine, die diese erstellt  – und wie könnte es anders sein: auch dieses Problem wurde bereits einmal gelöst.

Wandeln wir also auf den Spuren von Edsger W. Dijkstra.

Reverse Polish Notation

Der polnische Mathematiker Jan Łukasiewicz entwickelte etwa 1920 die sog. Polnische Notation für arithmetische Ausdrücke, die sich dadurch auszeichnete, dass jedem Operator (“+”, “-”, …) direkt seine Operanden (Zahlen oder weitere arithmetische Ausdrücke) folgten. Durch diese Präfixnotation ergibt sich die Möglichkeit, auf Klammern, Kommas, etc… verzichten zu können, wenn man weiß, wie viele Operanden ein Operator benötigt:

1+2+3         ==>        + 1 + 2 3           (auch: + + 1 2 3)
1+3*(4-2)     ==>        + 1 * 3 - 4 2
(3+4)*(4*3-1) ==>        * + 3 4 - * 4 3 1

Anhand des letzten Beispiels will ich die Auswertung so eines Ausdrucks beschreiben. Das Prinzip ist: “Werte den Ausdruck, der nur Zahlen als Operanden hat, als nächstes aus!”

   * + 3 4 - * 4 3 1        |   Das + bezieht sich auf 3 und 4!
=  * 7     - * 4 3 1        |   Das * bezieht sich auf 4 und 3!
=  * 7     - 12    1        |   Das - bezieht sich auf 12 und 1!
=  * 7     11               |   Das * bezieht sich auf 7 und 11!
=  77

Wie bereits erwähnt, funktioniert so eine Auswertung nur, wenn man weiß, wie viele Operanden/Parameter ein Operator/eine Funktion benötigt. Deswegen haben wir uns bei der Entwicklung des Lexers auch die Mühe gemacht, diese Information immer irgendwie bei der Hand zu haben.

Was Dijkstra nun gemacht hat, war, aus der Präfix- eine Postfixnotation zu machen, die sog. Reverse Polish Notation (RPN). Hier stehen nun alle Operanden vor dem Operator zu dem sie gehören:

1+2+3         ==>        1 2 3 + +          (auch: 1 2 + 3 +)
1+3*(4-2)     ==>        1 3 4 2 - * +
(3+4)*(4*3-1) ==>        3 4 + 4 3 * 1 - *

Sowohl Polish Notation als auch Reverse Polish Notation beschreiben (unter der Voraussetzung, dass man die Anzahl der Parameter/Operanden kennt) eine eindeutige Auswertungsreihenfolge. Bei der letztlichen Auswertung ist die RPN aber ihrem Vorfahren in Bezug auf Speicherverbrauch und Verständlichkeit dann doch voraus. Die Regel: “Wenn ein Operator auftaucht, werte ihn aus!”

Wir benötigen hierbei einen Stack, der die Zwischenergebnisse speichert und der diese bei Auftreten eines Operators zur Berechnung zur Verfügung stellt.

----------------------------------------------------------------------------------
Eingabe            | Stack    |  Kommentar
----------------------------------------------------------------------------------
3 4 + 4 3 * 1 - *  |          |  Beginn des Algorithmus
4 + 4 3 * 1 - *    | 3        |  Zahl (3): auf den Stack!
+ 4 3 * 1 - *      | 3 4      |  Zahl (4): auf den Stack!
4 3 * 1 - *        | 7        |  Operator (+): hole 3 und 4, berechne, speichere
3 * 1 - *          | 7 4      |  Zahl (4): auf den Stack!
* 1 - *            | 7 4 3    |  Zahl (3): auf den Stack!
1 - *              | 7 12     |  Operator (*): hole 4 und 3, berechne, speichere
- *                | 7 12 1   |  Zahl (1): auf den Stack!
*                  | 7 11     |  Operator (-): hole 12 und 1, berechne, speichere
                   | 77       |  Operator (*): hole 7 und 11, berechne, speichere
                   | 77       |  Eingabe leer, Ergebnis auf Stack.

Dies umzusetzen ist kein großes Problem und spricht in jedem Fall für die Reverse Polish Notation als Darstellung eines auszuwertenden Ausdrucks. Und dann wäre da noch die kleine, aber feine Tatsache, dass es einen Algorithmus gibt, der die Umwandlung “normaler” (Infix-)Ausdrücke (à la “1+2*f(3)”) in diese Notation vornimmt.

Der Shunting-Yard-Algorithmus

Der Shunting-Yard-Algorithmus (zu deutsch: Rangierbahnhofalgorithmus) ist eine ebenfalls von Dijkstra entwickelte Methode zur Umwandlung von Infix-Ausdrücken in Postfix-Notation. Sein Name kommt daher, dass seine Funktionsweise den Abläufen in einem Rangierbahnhof entspricht: alle terminalen Symbole (z.B. Zahlen, Variablen, …) sind Waren und Güter, die von Zügen (den nichtterminalen Symbolen wie Operatoren und Funktionen) mitgenommen werden müssen.

Die folgende Animation zeigt (vereinfacht) das Prinzip des Algorithmus. Er basiert darauf, dass in der Zugwarteschlange immer der Zug mit der höchsten Priorität (in der Realität z.B. die Geschwindigkeit) ganz vorne steht. Will sich ein langsamerer Zug einreihen, müssen also zuerst alle schnelleren Züge losgefahren sein. (Jeder Zug kann beliebig viele Waren transportieren und nimmt beim Abfahren alle verfügbaren mit! Es kann also auch passieren, dass ein Zug leer losfährt.)

Übertragen auf die Reverse Polish Notation: Die Operationen mit der niedrigsten Priorität werden zuletzt ausgeführt, entsprechen also den langsamsten Zügen. Mit ein wenig Überlegung sieht man, dass der Algorithmus also genau das Ergebnis liefern wird, was wir haben wollen!

Die Waren-Schlange kann übrigens in der letztlichen Implementierung entfallen, wenn man alle Waren einfach direkt zum Ausgang schiebt und immer nur den Zug voranstellt, der sie mitnehmen soll.

Hinzu kommt noch die Behandlung von Klammern und Trennsymbolen (z.B Kommas). Ich möchte den Algorithmus hier nicht im Detail aufschreiben, da der zugehörige Wikipedia-Artikel (englisch) eine genaue Beschreibung enthält.

Wichtig ist:

• Der Algorithmus kann Operatoren, Terminalsymbole, Klammern, Trennzeichen und Funktionen verarbeiten, d.h. wenn wir spezielle Konstrukte haben (z.B. “def x=a*(b-1)”) müssen wir diese erst in Funktionsform bringen. (z.B. “definition(x, a*(b-1))”)
• Der Algorithmus hat eine Laufzeit in O(n), d.h. er ist vergleichsweise effizient.

Reverse Polish Notation vs. Syntaxbaum

Eine weitere Möglichkeit, die Ausführungsreihenfolge eindeutig festzulegen, ist das Erstellen eines Syntaxbaumes. Für den Ausdruck “1+2*sqrt(e)” hat dieser z.B. die folgende Form:

               operator : +
              /            \
        integer : 1     operator : *
                       /            \
                  integer : 2   function : sqrt
                                     |
                                constant : e

Die Auswertung erfolgt von unten nach oben, d.h. bei der letztlichen Berechnung würden folgende Schritte ausgeführt:

e                 => 2.71
sqrt(2.71)        => 1.65
2                 => 2
2 * 1.65          => 3.3
1                 => 1
1 + 3.3           => 4.3

Das besondere ist, das jeder Syntaxbaum sehr einfach in Reverse Polish Notation umgewandelt werden kann und jede RPN ebenso einfach in einen Syntaxbaum.

Für erstere Umwandlung durchläuft man den Baum als Post-Order-Traversierung, d.h. man schreibt ausgehend von der Wurzel zuerst die Post-Order-Notation der Kindknoten auf und hängt anschließend den Wert der Wurzel daran an.

Für die entgegensetzte Transformation tut man so, als würde man die RPN-Notation auswerten (siehe oben!), aber anstatt auf dem Stack Zwischenergebnisse zu speichern, sichert man dort die Teilbäume:

-----------------------------------------------------------------------------------
Eingabe            | Stack           |  Kommentar
-----------------------------------------------------------------------------------
3 4 + 4 3 * 1 - *  |                     |  Beginn des Algorithmus
4 + 4 3 * 1 - *    | 3                   |  Zahl (3): Blatt auf den Stack!
+ 4 3 * 1 - *      | 3 4                 |  Zahl (4): Blatt auf den Stack!
4 3 * 1 - *        | +(3,4)              |  Operator (+): hole Blätter, bilde Baum
3 * 1 - *          | +(3,4) 4            |  Zahl (4): Blatt auf den Stack!
* 1 - *            | +(3,4) 4 3          |  Zahl (3): Blatt auf den Stack!
1 - *              | +(3,4) *(4,3)       |  Operator (*): hole Blätter, bilde Baum
- *                | +(3,4) *(4,3) 1     |  Zahl (1): Blatt auf den Stack!
*                  | +(3,4) -(*(4,3), 1) |  Operator (-): hole Blatt/Teilbaum, bilde Baum
[...]

Ergebnis: *(+(3,4), -(*(4,3), 1))

Ich hoffe die Baumnotation “Wurzel(Teilbaum1, Teilbaum2, …)” ist verständlich.

Es gibt hierzu noch eine weitere wichtige Anmerkung:
Jeder Algorithmus, der die Reverse Polish Notation eines Ausdrucks erstellen kann, kann so modifiziert werden, dass er einen Syntaxbaum erstellt und jeder Algorithmus, der einen Syntaxbaum erstellt, kann auch die RPN eines Ausdrucks erstellen!

Beide Darstellungen sind also gleichwertig in der Funktionalität, der Syntaxbaum benötigt jedoch mehr Speicherplatz, außerdem ist eine Auswertung des Baumes auf rekursivem Weg ebenfalls nicht gerade resourcenschonend.

Fazit

Auch wenn die Reverse Polish Notation eines Ausdrucks Verarbeitungsvorteile mit sich bringt, erschwert sie die Untersuchung der Eingabe auf syntaktische Korrektheit (vor allem Typkorrektheit!). Unser Parser muss also intern einen Syntaxbaum erstellen, diesen überprüfen und anschließend die RPN des Ausdrucks ausgeben. Damit dürften wir auf der sicheren Seite sein.

Nur: Was ist eigentlich Syntax?

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax
   

Vor allem die letzte Frage kann einem zu schaffen machen. Warum etwas möglicherweise nicht gut funktionierendes entwickeln, wenn es doch überall schon tausendfach durchdachte Lösungen gibt? Immerhin lautet doch eine der obersten Regeln in der Softwareentwicklung:

Don’t reinvent the wheel!

Nun, ich bin Informatikstudent. Ich will wissen, wie die Dinge “unter der Haube” aussehen, ich will lernen. Und wenn alle nur noch auf vorgefertige Bibliotheken zurückgreifen, weiß doch bald keiner mehr, was dem Zauber eigentlich zugrunde liegt… Dementsprechend:

Don’t reinvent the wheel, unless you plan on learning more about wheels!

Diese Anleitung soll jedem helfen, der interessiert daran ist, was im Inneren eines Interpreters oder Compilers eigentlich (ungefähr so) abläuft. Ich selbst habe gerade erst das zweite Semester hinter mir, d.h. allzu theoretisch wird es hier nicht und jeder mit ein wenig logischem Denken und genug Engagement sollte es hinbekommen, meinen Ausführungen zu folgen.

Lasset uns beginnen.

Der Lexer

Ein lexikalischer Scanner (kurz: Lexer) ist eine “Maschine”, die eine Zeichenfolge als Eingabe erhält und diese in kleinere Teile spaltet, denen eine bestimmte Bedeutung/ein bestimmter Typ zugrunde liegt.

Ein Taschenrechner, beispielsweise, kennt Zahlen, Operatoren und Klammern. Gibt man dem Lexer dieses Taschenrechners nun die Folge “1+2*(4-3)” zur Verarbeitung, wird daraus die folgende (oder eine ähnliche) Liste:

zahl        :    1
operator    :    +
zahl        :    2
operator    :    *
open        :    (
zahl        :    4
operator    :    -
zahl        :    3
close       :    )

Die einzelnen Zeilen nennt man Tokens. Sie bestehen aus einem Typ (“zahl”, “operator”, …) und einem Wert (“1″, “+”, …) und kapseln somit alle Informationen, die man benötigt, um damit weiterzuarbeiten.

Wichtig ist folgendes: der Lexer überprüft nicht den “Sinn” der Eingabe, d.h. auch ein nicht wohlgeformter Ausdruck wie “1+)(*2″ würde von ihm brav und folgsam in eine Liste von Tokens umgewandelt werden. Die semantische Überprüfung erfolgt an anderer Stelle: dem Parser.

Prinzip

Wie schreibe ich einen Lexer? Das ist keine allzu schwere Sache, die Frage ist nur, wie effizient er letztlich ist. Ich werde hier verschiedene Ansätze darstellen, die jeweils Vor- und Nachteile haben.

Ansatz 1: Reguläre Ausdrücke auf den Anfang der Eingabesequenz anwenden
(~ nicht naiv, aber auch nicht so der Hammer)

• Der Lexer verwaltet eine Reihe von Datentypen, die durch reguläre Ausdrücke (Testen kann man z.B. hier) eindeutig definiert sind. Also z.B.:

  zahl   =>    [0-9]+
  id     =>    [a-zA-Z]+
  open   =>    \(
  close  =>    \)
  comma  =>    ,
  op     =>    [+\-]
  ...

• Auf Basis dieser Typen erfolgt nun die Umwandlung einer Eingabezeichenfolge in Tokens:
  • Erstelle eine leere Ausgabeliste.
  • Während die Zeichenfolge nicht leer ist:
    1. Vergleiche den Anfang der Zeichenfolge mit den regulären Ausdrücken aller verfügbaren Datentypen, bis du einen Treffer landest.
    2. Kein Treffer: Die Zeichenfolge enthält einen unbekannten Datentyp!
    3. Ansonsten:
       • Schneide den gefundenen Ausdruck von der Eingabezeichenfolge ab.
       • Erstelle ein Token des gefundenen Typs und hänge es an die Ausgabeliste an.
    4. Gib die Ausgabeliste aus.
• Ein Token enthält (wie bereits erwähnt) den Typ und Wert eines Ausdrucks. Des weiteren könnte es sich anbieten, auch jeweils Verweise zum vorhergehenden und nachfolgenden Token bereitzustellen, die ja Einfluss auf den realen Typ eines Tokens haben können.
  (Ein Plus benötigt z.B. normalerweise zwei Parameter, wenn aber vor dem Plus ein anderer Operator und danach eine Zahl steht, ist diese Zahl der einzige Parameter und das Plus ist ein Vorzeichen. Die Methode, die solche Sachen überprüft, sollte in der Implementierung der Datentypen auftauchen!)

Der Vorteil dieser Methode ist die Erweiterbarkeit. Wenn man einen neuen Typen hinzufügen will, erstellt man einfach den dazugehörigen Ausdruck. Den Rest übernimmt der Lexer.

Ein gewaltiger Nachteil ist die Zuverlässigkeit: oft gibt es Mehrdeutigkeiten bei regulären Ausdrücken und der Lexer weiß nicht, welcher gerade der richtige ist. Außerdem lässt die Geschwindigkeit zu wünschen übrig: Im schlimmsten Fall (die gesamte Eingabe besteht aus n Tokens des gleichen Typs und dieser Typ ist der letzte, der überpürft wird) beträgt  bei einer Gesamtzahl von m Datentypen die Laufzeit: O(n*m*O(regulärer Ausdruck)) also vermutlich irgendetwas im Bereich O(m*n²)

Ansatz 2: Spezialisierung auf bekannte Eingabetypen
(~ naiver Ansatz)

Wenn man den Lexer nicht für beliebige Datentypen und -formate ausrichtet, sondern von vornherein weiß, wie viele es davon gibt und wie sie aussehen, kann man die Realisierung einfacher/verständlicher machen:

1. Initialisiere einen Zähler i mit 0 und eine leere Liste für die Ausgabe.
2. Während i kleiner ist als die Länge der Eingabe:
   • Überprüfe das i-te Zeichen.
   • Wenn es eine Zahl ist, erhöhe i so lange um eins, bis das i-te Zeichen keine Zahl mehr ist und erstelle aus den dabei “überstrichenen” Zeichen ein Token des Typs “integer”. (Erstellt Token für Zahlen.)
   • Wenn es ein Buchstabe ist, erhöhe i so lange um eins, bis das i-te Zeichen weder Zahl noch Buchstabe ist und erstelle aus den dabei überstrichenen Zeichen ein Token des Typs “identifier”. (Erstellt Token für Variablen)
   • Wenn es ein Anführungszeichen ist, erhöhe i so lange um eins, bis das i-te Zeichen ebenfalls ein Anführungszeichen und das (i-1)-te Zeichen kein Backslash ist [...] (Erstellt Token für Strings)
   • usw…
   • Hänge das erstellte Token an die Ausgabeliste an.
3. Gib die Ausgabeliste aus.

Der Vorteil ist ganz klar die Geschwindigkeit: Jedes Zeichen der Eingabesequenz wird höchstens zweimal überprüft, d.h. die Laufzeit liegt in O(n).

Nachteile sind hier die umständliche Erweiterbarkeit, sowie der meist aufgeblähte Code.

Ansatz 3: Endlicher Automat
(~ professionell und kompliziert (?))

Ansatz 2 war schon nichts anderes als die prinzipielle Funktionsweise eines endlichen Automaten: Ausgehend von einem aktuellen Zustand (z.B. “Kein Zeichen überprüft”, “Stringbeginn entdeckt”) und einer Eingabe (z.B. das nächste Zeichen) geht der Automat in einen neuen Zustand (z.B. “Unerlaubtes Zeichen”, “Stringinhalt”) über. Wenn irgendwann ein Ausgabezustand erreicht wird, erhält man das gerade gelesene Token.

Wenn wir beispielsweise nur die Schlüsselwörter “echo” und “echtheit” hätten, ergäbe sich folgender Automat. (Startsymbol: S, Endsymbol E):

                                         "echo" -----> E("echo")
    e          c           h          o /
S -----> "e" -----> "ec" -----> "ech"
                                      t \         h              e
                                         "echt" -----> "echth" -----> ... -----> E("echtheit")

Wenn ein Zustandsübergang nicht möglich ist, hat man es mit einer unerlaubten Sequenz zu tun. Ein detaillierteres Beispiel zur Modellierung eines endlichen Automaten findet man hier.

Das besondere an endlichen Automaten ist, dass jeder reguläre Ausdruck in so einen Automaten verwandelt werden kann. Eine detaillierte Beschreibung für Interessierte gibt es hier (Uni Bremen).

Vor- und Nachteile entsprechen Ansatz 2, die Laufzeit beträgt ebenfalls O(n). Endliche Automaten werden von fast allen Lexer-/Parser-Generatoren (auf Basis einer Grammatik) erstellt, sind also der meistverbreitete Ansatz zum Erstellen eines Lexers.

Ansatz 4: “Akzeptanztest” auf Basis vieler kleiner Typ-Automaten
( ~ Symbiose von Ansatz 1 und 3)

Ich stand also nun vor dem Problem, zwischen Effizienz und Erweiterbarkeit abzuwägen – genauer gesagt: mich für eines von beiden entscheiden zu müssen – und das passte mir nicht wirklich. Also, zur Ablenkung mal weg vom Schreibblock und Computer, zum Lidl einkaufen und Flaschen zurückbringen. Was man halt so tut.

Und da war er: ein Pfandflaschen-Rückgabe-Automat, der nichts anderes tat, als tagein, tagaus Flaschen anzunehmen und zu überprüfen. Passte die Flasche, gab es einen Zettel, der bares Geld wert war, passte sie nicht, eine Fehlermeldung.

Warum erzähle ich das? Nun, dieser Automat war die Lösung für mein Problem!
Man braucht viele kleine, auf einen bestimmten Typ (von Token, von Flaschen, …) spezialisierte Automaten, die anhand der bereits zuvor eingegebenen Daten (gelesene Zeichen, akzeptierte Flaschen, …) sagen, ob sie eine Eingabe (das nächste Zeichen, die nächste Flasche, …) akzeptieren. Oder eben nicht.

Das Beispiel aus Ansatz 3  würde hierbei so realisiert: Sowohl der “echo”-Automat, als auch der “echtheit”-Automat würden die Eingaben “e”, “c” und “h” (in dieser Reihenfolge) akzeptieren, aber wenn nun ein “o” kommt, wird sich der “echtheit”-Automat aufregen. Für die weitere Überprüfung kann er also ignoriert werden. Und erst wenn auch der “echo”-Automat nicht mehr weitermachen will (also nach besagtem “o”), hat man sein Token gefunden und kann es über die Ausgabefunktion des Automaten auslesen.

Allgemein: Man habe eine Menge A von Typ-Automaten und eine Eingabesequenz <s₀, s₁, s₂, s₃, …, s_n>

1. Versetze alle Automaten in A in ihren Ausgangszustand. (Reset)
2. Finde alle Automaten in A, die s₀ akzeptieren und bilde aus ihnen die Menge A₀
3. Initialisiere i mit 0. Während 0 <= i < n:
   • Wenn |A_i| = 0: brich Schleife ab.
   • Ansonsten: Finde alle Automaten in A_i, die s_i+1 akzeptieren und bilde aus ihnen die Menge A_i+1
   • Erhöhe i um 1.
4. Wenn i=0: Ungültiger Ausdruck.
5. Ansonsten: Finde einen  passenden Typ aus A_i-1 bis A₀, der sich in einem Ausgabezustand befindet (der Index der entsprechenden Automatenmenge sei j), und erstelle ein Token mit dem Wert <s₀, s₁,…, s_j> und dem gefundenen Typen.
6. Fahre mit der restlichen Eingabesequenz fort.

Betrachten wir die Laufzeit: Schritt 1 liegt in O(|A|), Schritt 2 ebenfalls. Schritt 3 benötigt im schlimmsten Fall (die Zeichenfolge wird von allen Automaten komplett akzeptiert) eine Laufzeit von O(n*|A|). Schritt 5 kann ebenfalls eine Laufzeit in O(n*|A|) erreichen, wenn kein einziger Automat in einem Ausgabezustand ist, die restlichen Schritte haben einen konstanten Zeitbedarf O(1).

Diese Methode ermittelt also den nächsten Token mit einer Laufzeit von O((2n+2)*|A|+1), also O(n*|A|). Gleichzeitig ist Erweiterbarkeit gewährleistet, da die Typ-Automaten sehr leicht zu implementieren sind und der Lexer sie nicht von vornherein kennen muss.

Zuverlässigkeit ist nur in Schritt 5 fraglich: Was ist der “passende Typ” zu einem Token? Hier könnte man ein hierarchisches System einführen, das z.B. festlegt: “Wenn die Wahl zwischen dem Typ Funktion und dem Typ Bezeichner getroffen werden muss, nimm die Funktion!”

Die Funktion eines Integer-Automats, die überprüft, ob ein Zeichen akzeptiert wird, könnte z.B. so aussehen:

public bool Accept(char c)
{
    switch (char)
    {
        case '0': case '1': case '2': case '3': case '4':
        case '5': case '6': case '7': case '8': case '9':
            return true;
        default:
            return false;
    }
}

Damit kann man leben, oder? Schwieriger wird es erst bei solchen Sachen wie Strings, wo z.B. beachtet werden muss, dass ein gültiges Zeichen, das nach dem Schließen des Strings kommt, natürlich nicht mehr akzeptiert werden darf. (Man müsste also im Automaten selbst weitere Zustandsdaten, z.B. einen boolschen Wert stringClosed oder so, speichern.)

Fazit

Um eine größtmögliche Erweiterbarkeit zu gewährleisten und weil ich stolz auf die Idee bin und überprüfen will, wie sie sich umsetzen lässt, werden wir Ansatz 4 implementieren. Ich frage mich allerdings, was “Pfandflaschenalgorithmus” auf Englisch heißt…

Update (30.08.2009):
Eine bessere Analogie für den Algorithmus wäre statt dem Pfandflaschenautomaten wohl ein Rennen oder ein Wettbewerb: derjenige, der am weitesten kommt (“die meisten Eingaben akzeptiert), ist der Sieger – außer er bricht dann zusammen, fängt an zu heulen, etc… (“außer er befindet sich nicht in einem Ausgabezustand”) In dem Fall gewinnt der zweite Platz (der aber identisch mit dem ersten sein kann), außer auch dieser kommt mit dem Druck nicht klar. Und so weiter.

Implementierung

Bei der Implementierung des Lexers sollten gleich alle verfügbaren Datentypen (Operator, Trennzeichen, Terminalausdruck, …) in eigenen Klassen gekapselt werden. Das macht die spätere Verwendung einfacher.

Zwei Sachen sollten hier näher erläutert werden. Zuerst die Methode signification der Klasse SyntaxType: sie ermittelt anhand eines konkreten Tokens den “wirklichen Typ” dieses Tokens. Man könnte z.B. einen Grundtyp Identifier definieren (als Unterklasse von Terminal), der alle Buchstabenfolgen (keine Zahlen, keine Sonderzeichen) repräsentiert. Die signification-Methode könnte dann ermitteln ob der Identifier eine Variable, ein Listenname, eine Konstante, etc… ist und dies zurückliefern. Oder eben oben genanntes Beispiel mit dem Pluszeichen, das abhängig vom Kontext ein Operator oder ein Vorzeichen sein kann.

Zweitens das Interface IStateMachine: Es kapselt die für Ansatz 4 (s.o.) benötigten Operationen. (Die Methode IsOutputState fehlt, sollte aber nicht vergessen werden!)

Update (12.08.2009):
Datentypen, die spezielle, angepasste Methoden signification benötigen, müssen als Unterklassen der jeweiligen Typen (hauptsächlich Terminal vermutlich) definiert werden und die Methoden überschreiben. Nur, falls das noch nicht klar war.

Gesamtfazit

Nun kommen wir leicht an die einzelnen Bestandteile eines Ausdrucks, aber uns fehlen noch die Mittel, damit richtig umzugehen. Der nächste Schritt ist es also, Regeln für unsere verschiedenen Ausdrücke zu erstellen (Welche Art von Parametern benötigt eine Funktion/ein Operator/ein Pattern? Darf eine Funktion verschachtelt ausgeführt werden? Etc…) und anhand dieser Regeln einen gegebenen Ausdruck zu überprüfen und in eine einfach weiterzuverarbeitende Form zu bringen.

Hier kommt der sog. Syntaxbaum ins Spiel. Und der Parser, der ihn erstellt.

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax
   

Vorspiel

Neben LastSharp und LeSharp, den beiden Tools, die für eine breite Masse gedacht und deshalb auch zumindest ein bisschen nützlich sind, arbeite ich noch an zwei eher theoretischen Projekten: UVD (das im Moment ruht) und Lapicon (Loose API Connection Language).

Letzteres ist eine Scriptsprache zum Senden und Verarbeiten von REST-Requests, also zum Verwenden verschiedenster APIs, z.b. dem von Last.FM. Kein großer Leckerbissen für den Otto-Normal-Benutzer also und auch für Entwickler, die sich mit dem Thema beschäftigen, ist die Sprache nicht der Inbegriff von Eleganz. Deshalb mein Entschluss: Lapicon muss von Grund auf neu entwickelt werden. Das bedeutet: neue Funktionen, mehr Komfort, bessere Performance, usw… Alles in allem keine triviale Aufgabe.

Und dann kam mir die Idee, meinen Versuch zu protokollieren und somit allen, die daran interessiert sind, eine eigene Programmier- oder Scriptsprache zu entwickeln, ein Stückchen weiterzuhelfen. Eine kleine Reise, ein kleines Abenteuer also.

Ein Hinweis

Das Konzept, das hier entwickelt wird, eignet sich für Sprachen, die – so will ich es jetzt aus Ermangelung eines Fachbegriffs mal nennen – “blockbasiert” sind, also so etwa wie Pascal oder VHDL. D.h. man hat (z.B. bei Funktionen) immer einen Start- und einen Endblock, wobei der Endblock überflüssig werden kann, wenn man Sachen wie Zeileneinrückung einbezieht. (Ein Konzept, dass ich, während ich mich in Ruby eingearbeitet habe, bei HAML und SASS kennen- und schätzen gelernt habe.)

Des weiteren werden wir zur Erkennung verschiedener Anweisungen mit Regular Expressions arbeiten, weshalb man sich dort auskennen sollte. Ein Tutorial gibt es z.B. hier (englisch).

Reisevorbereitung

Bevor wir uns überhaupt mit der Sprache selbst beschäftigen, sollten wir folgendes tun:

1. Wir müssen uns überlegen, welche Komponenten wir entwickeln müssen, um Ausdrücke zu erkennen und zu verarbeiten.
   Die Schlagworte hier sind Lexer und Parser. (Ich hatte anfangs ein anderes Konzept vorgesehen, das aber einen Haufen Schwächen hatte, weshalb ich jetzt doch wieder auf das klassische Prinzip zurückkomme. Ich werde mich bemühen, das so gut wie möglich darzustellen…)

   Der Lexer nimmt einen Ausdruck und zerlegt ihn in sog. Token, d.h. in kleine Teile, die einen Typ und einen Wert besitzen. Man nehme beispielsweise den Ausdruck “1+2*sqrt(e)”. Ein Lexer (auch Tokenizer genannt) könnte daraus eine Liste der folgenden Gestalt fabrizieren:

   integer  : 1
   operator : +
   integer  : 2
   operator : *
   id       : sqrt
   open     : (
   id       : e
   close    : )

   Der Parser nimmt nun diese Liste und erstellt daraus einen Syntaxbaum, d.h. eine Repräsentation des Ausdrucks als Baumstruktur. Hier wird vor allem darauf geachtet, dass verschiedene Operatoren verschiedene Prioritäten haben können, dass es Verschachtelungen durch Klammern gibt, etc… Ein Syntaxbaum für unser Beispiel könnte nach dem Parsen z.B. so aussehen:

                  operator : +
                 /            \
           integer : 1     operator : *
                          /            \
                     integer : 2   function : sqrt
                                        |
                                   constant : e

2. Wir müssen festlegen, was die Sprache können soll.
   Welche Datenstrukturen sollen zugänglich sein? Kann man Funktionen definieren? Gibt es arithmetische Operationen? Schleifen? Man sollte sich eine Liste machen. Für unsere Beispielsprache könnte das so aussehen:
   • Es gibt zwei Datentypen: Zahlen und Strings.
   • Es gibt Variablen, die aber nur Zahlen enthalten können.
   • Es gibt eine Ausgabefunktion, die Strings und Zahlen ausgibt.
   • Es gibt eine Ausgabefunktion, die Zeilenumbrüche erzeugt.
   • Es gibt eine Eingabefunktion, die Zahlen einliest und in einer Variablen speichert.
   • Es gibt die arithmetischen Operationen Addition (+), Subtraktion (-), Multiplikation (*), Division (/), die auf ganzen Zahlen arbeiten.
   • Es gibt Klammern, mit denen man die Ausführungsreihenfolge beeinflussen kann.
   • Es gibt eine Schleife, die einen Befehl genau n-mal (n ist gegeben) ausführt.
   • Es gibt drei Funktionen, die jeweils überprüfen, ob eine Zahl größer, kleiner oder gleich 0 ist und bei zutreffendem Ergebnis, einen Fehler ausgeben.

   Was wir also entwickeln werden, ist ein Taschenrechner.

3. Wir müssen uns Gedanken dazu machen, wie der Interpreter aufgebaut ist und arbeitet.
   Wie genau wird unser Programmcode verarbeitet? Wie arbeitet der Interpreter intern?An dieser Stelle wird klar, warum ich mich dafür entschieden habe, eine “blockbasierte” (also mit expliziten Blockanfängen und -enden) Sprache zu entwickeln: es ermöglicht die Ausführung eines Programms Zeile für Zeile. (Zwar wäre es kein unerträglicher Aufwand, auch so etwas wie Klammerstrukturen, ähnlich zu C#, unterstützen zu lassen, aber es geht auch so – und macht außerdem den Quelltext strukturierter, wie man z.B. an Ruby sieht.)

   Das andere Konzept, das den Interpreter zu einem nützlichen Interpreter macht, habe ich bei der Mikroprogrammierung näher kennengelernt. Man hat einen Instruktionszeiger (Instruction Pointer, IP), der auf die aktuelle Instruktion zeigt und einen Stack, der den Wert des Zeigers zwischenspeichern kann. Jede Anweisung sagt dem Interpreter nach ihrer Ausführung, was er nun weiter machen soll. Zyklus:

   1. Hole die Anweisung (Statement), auf die der IP gerade zeigt. Ist keine Anweisung vorhanden, brich ab.
   2. Übergib die Anweisung an den Verarbeiter (Processor) und speichere das Ergebnis.
   3. Lies aus dem Ergebnis die folgenden Teile aus: Zeiger-Offset, Zeiger-Aktion und Stack-Aktion.
   4. Wenn die Stack-Aktion “PUSH” ist, lege den IP auf den Stack.
   5. Wenn die Zeiger-Aktion “NULL” ist, setze den IP auf 0, ist sie “STACK”, setze den IP auf die Position, die zuoberst auf dem Stack liegt. Bei “CONTINUE” erhöhe den IP um 1.
   6. Wenn die Stack-Aktion “POP” ist, nimm das oberste Element vom Stack.
   7. Addiere den Zeiger-Offset auf den Instruktionszeiger.
   8. Gehe zu 1.

   Beispiel: Schleife, die mindestens einmal ausgeführt wird
   (Notation: Zeiger-Offset, Zeiger-Aktion, Stack-Aktion)

   Schleifenbeginn: 0 / CONTINUE / PUSH
   Schleifenrumpf: beliebig
   Schleifenbedingung erfüllt: 1 / STACK / NONE
   Schleifenbedingung nicht erfüllt: 0 / CONTINUE / POP

   Beispiel 2: Funktionsaufruf

   Aufruf: <Adresse+1> / NULL / PUSH
   Rumpf: beliebig
   Rücksprung: 1 / STACK / POP

   Der Processor ist das, wo die eigentliche Ausführung  eines Befehls stattfindet. Er tut folgendes:

   1. Erstelle mithilfe von Lexer und Parser (siehe oben) den Syntaxbaum des Befehls.
   2. Wenn der Baum Kindknoten hat, werte zuerst die jeweiligen Teilbäume aus. (Top-Down-Methode)
   3. Schaue, ob für den Typ des Wurzelknotens eine Verarbeitungsroutine (Evaluator) existiert. Wenn ja, rufe sie mit den in 2. ermittelten Daten auf und gib ihr Ergebnis zurück, wenn nicht, gib eine Fehlermeldung aus und brich die Gesamtausführung ab.
4. Und wie werden die programminternen Daten gespeichert?
   Wir benötigen eine Umgebung, in der ein Programm läuft. Diese Umgebung hat vor allem die Aufgabe, Variablen, Objekte, Funktionen, Listen, Arrays, etc… zu verwalten, also eine große Menge an Daten zu speichern und zugreifbar zu machen. Wenn man von vornherein weiß, was auf einen zukommt (wenn man also einen Interpreter für eine ganz bestimmte und ganz genau definierte Sprache schreibt), kann man es sich einfach machen:
   • einen Speicher für Variablen,
   • einen Speicher für Funktionen,
   • einen Speicher für Listen,
   • …

   Die Realisierung als Hashtabelle (Wörterbuch, Dictionary) würde sich für jeden einzelnen dieser Speicher anbieten. Eine Hashtabelle ist eine Liste von Schlüssel-Wert-Paaren, wo jeder Wert schnell über seinen Schlüssel adressiert werden kann – in obigem Fall wären folgende Zuordnungen sinnvoll:

   • [Variablenname => Variablenwert]
   • [Funktionsname => (Funktionsbeginn (Zeiger), Funktionsende (Zeiger))]
   • [Listenname => Liste]
   • …

   In meinem Studium wird mir beigebracht, alles so abstrakt wie möglich zu halten, weswegen ich die nun folgende Lösung vorschlage. Hierbei benötigen wir nur zwei Hashtabellen (plus eine geschachtelte) und haben zum einen den Vorteil, dass wir beliebige Daten speichern können, zum anderen, dass die Überprüfung auf doppelte Bezeichner (Variablen-, Funktions- und Listennamen sollten ja nur einmal vorkommen!) sehr einfach wird:

   • Wir verwenden eine Tabelle, um jedem Bezeichner einen Typ zuzuweisen. ([Bezeichner => Typ])
   • Wir verwenden eine weitere Tabelle, um jedem Typ eine weitere Hashtabelle zuzuweisen, die wiederum jeden Bezeichner mit seinem Wert verknüpft. ([Typ => [Bezeichner => Wert]])

   Mit entsprechenden Operationen auf diesen beiden Tabellen haben wir nun unsere Umgebung (Environment).

Nachdem wir das alles beantwortet haben, können wir loslegen. Aber Halt! Einen wichtigen Punkt haben wir noch nicht angesprochen: Wie verwende ich Regular Expressions so, dass ich zum einen leicht feststellen kann, welchen Anweisungstyp ich vor mir habe, und zum anderen einfach an die gewünschten Daten komme?

Das ist der Punkt, an dem wir unsere praktische Arbeit beginnen werden.

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax