MiniJavaCompiler/doc/parser.tex

\section{Lexer \& Parser}
\subsection{Lexer}

Der Lexer wurde mit dem Alex tool implementiert. Dieser ist dafür zuständig den langen String in einzelne Tokens umzuwandeln. In der Alex Datei gibt es für jedes Token einen regulären Ausdruck. Bei den meisten Tokens ist das einfach das Schlüsselwort. Etwas komplexer waren Identifier, Integerliterale Strings und Chars. Für die Definition wurde sich eng an die offizielle Java Language Specification gehalten. Es ist beispielsweise auch möglich Unterstriche in Integerliterale einzubauen (Bsp.: \verb|234_343_000|) Es sind fast alle Schlüsselwörter von Java im Lexer implementiert, auch wenn nicht alle davon vom Parser geparst werden können. Whitespace und Kommentare werden direkt ignoriert und verworfen. Für Charliterale und Integerliterale gibt es auch spezielle Fehlermeldungen. Die meisten Tokens haben nur die Information, zu welchem Keyword sie gehören. Eine Ausnahme bilden der Identifier und die Literale. Für den Identifier wird noch der Name gespeichert und für die Literale der entsprechende Wert. Mit der Funktion alexScanTokens kann dann ein beliebiger String in Tokens umgewandelt werden.

Die komplexeren Tokens haben Unittests, welche mit dem Testframework HUnit geschrieben wurden. Es gibt Tests für Kommentare, Identifier, Literale und ein paar weitere Tokens.

\subsection{Parser}

Der Parser wurde mit dem Happy tool implementiert. Er baut aus einer Liste von Tokens einen ungetypten AST. Wir haben bereits eine Grammatik bekommen und mussten für die einzelnen Regeln noch die Rückgabewerte angeben.

Um den Parser aufzubauen wurde zuerst ein Großteil der Grammatik auskommentiert und Stück für Stück wurden die Rückgabewerte hinzugefügt. Immer wenn ein neues Feature umgesetzt wurde, wurde dafür ein weiterer Unit Test geschrieben. Es gibt also für jede komplexe Ableitungsregel mindestens einen Unittest.

\subsubsection{Klassenaufbau}
Als erstes wurden leere Konstruktoren Methoden und Felder umgesetzt. Da in Java Konstruktoren, Methoden und Felder durcheinander vorkommen können geben die Ableitungsregeln einen Datentyp namens MemberDeclaration zurück, welcher eines von den drei enthalten kann. Die \verb|classbodydeclarations| Regel baut dann einen 3-Tupel mit einer Liste aus Konstruktoren, einer aus Methoden und einer aus Feldern. Über Pattern Matching werden diese Listen dann erweitert und in der darüberliegenden Regel schließlich extrahiert.

\pagebreak
Bei folgender Klasse:
\begin{lstlisting}[language=Java]
class TestClass {
    int field;

    TestClass() {}

    void foo() {}
}
\end{lstlisting}
würde die Regel folgendes Tupel zurückgeben:
\begin{lstlisting}[language=Haskell]
(
    [ConstructorDeclaration "TestClass" [] (Block [])],
    [MethodDeclaration "void" "foo" [] (Block [])],
    [VariableDeclaration "int" "field" Nothing]
)
\end{lstlisting}
und folgende Klasse wird erstellt
\begin{lstlisting}[language=Haskell]
Class "TestClass" 
    [ConstructorDeclaration "TestClass" [] (Block [])]
    [MethodDeclaration "void" "foo" [] (Block [])]
    [VariableDeclaration "int" "field" Nothing]
\end{lstlisting}
Das Nothing ist in diesem Fall ein Platzhalter für eine Zuweisung, da unser Compiler auch Zuweisung bei der Felddeklaration unterstützt.

\subsubsection{Syntactic Sugar}

In Java ist es möglich mehrere Variablen in einer Zeile zu deklarieren (Bsp.: \verb|int x, y;|). Beim Parsen ergibt sich dann die Schwierigkeit, dass man in dem Moment, in dem man die Variable parst, nicht weiß welchen Datentyp diese hat. Aus diesem Grund gibt es den Datentyp Declarator, welcher nur den Identifier und eventuell eine Zuweisung enthält. In den darüberliegenden Regeln \verb|fielddeclaration| und \verb|localvariabledeclaration| wird dann die Typinformation hinzugefügt mithilfe der Funktion \verb|convertDeclarator|.

Für die Zuweisung wird auch die Kombination mit Rechenoperatoren unterstützt. Das ganze ist durch Syntactic Sugar im Parser umgesetzt. Wenn es einen Zuweisungsoperator gibt, dann wird der Ausdruck in eine Zuweisung und Rechnung aufgeteilt. Bsp.: \verb|x += 3;| wird umgewandelt in \verb|x = x + 3|.

For-Schleifen wurden auch rein im Parser durch Syntactic Sugar implementiert. Eine For-Schleife wird dabei in eine While-Schleife umgewandelt. Dafür wird zuerst ein Block erstellt, sodass die deklarierten Variablen auch nur für den Bereich der Schleife gültig sind. Die Bedingung der For-Schleife kann in die While-Schleife übernommen werden. Innerhalb der While-Schleife folgen zuerst die Statements, die im Block der For-Schleife waren und danach die Update-Statements.

\begin{lstlisting}[language=Java]
for (int i = 0; i < 9; i++) {
    foo();
}
\end{lstlisting}
wird umgewandelt in:
\begin{lstlisting}[language=Java]
{
    int i = 0;
    while (i < 9) {
        foo();
        i++;
    }
}
\end{lstlisting}

Es wurden auch Parameter mit Standardwerten im Parser implementiert. Dieses Feature ist in der aktuellen Java Version (Java 22) noch nicht implementiert. Der Parser macht sich dafür das Überladen von Methoden zunutze. Er generiert für jedes Parameter mit Standardwert eine weitere Funktion, welche die ursprüngliche Funktion mit einem Standardwert aufruft.

%\lstinputlisting[language=Java,firstline=7,lastline=9]{../Test/JavaSources/TestOptionalParameter.java}
\begin{lstlisting}[language=Java]
int normalAndOptional(int a, int b = 2, int c = 3) {
    return a + b + c;
}
\end{lstlisting}
wird umgewandelt in:
\begin{lstlisting}
int normalAndOptional(int a) {
    return normalAndOptional(a, 2);
}
int normalAndOptional(int a, int b) {
    return normalAndOptional(a, b, 3);
}
int normalAndOptional(int a, int b, int c) {
    return a + b + c;
}
\end{lstlisting}