update pdf

doc/parser.tex

@@ -1,35 +1,65 @@
 \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.
+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.
-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.
+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.
-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.: \texttt{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.
+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 diese noch in den AST umwandeln.
-Wir haben bereits eine Grammatik bekommen und mussten diese noch in den AST umwandeln.
+
-Um den Parser aufzubauen wurde zuerst ein Großteil der Grammatik auskommentiert und Stück für Stück wurden die Umwandlungen hinzugefügt.
+Um den Parser aufzubauen wurde zuerst ein Großteil der Grammatik auskommentiert und Stück für Stück wurden die Umwandlungen 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.
-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. Als erstes wurden leere Methoden und Felder umgesetzt.
+\subsubsection{Klassenaufbau}
-Da in Java Methoden und Felder durcheinander vorkommen können geben die Ableitungsregeln einen Datentype namens \texttt{MethodOrFieldDeclaration} zurück.
+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. Die 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.
-Über Pattern Matching baut die classbodydeclarations Regel dann eine Tupel mit einer Liste aus Methoden und einer aus Feldern.
+
-Über pattern matching werden diese Listen dann erweitert und in der darüberliegenden Regel schließlich extrahiert.
+Bei folgender Klasse:
-Die Konstruktoren sind in diesem Fall auch normale Methoden mit dem Rückgabewert `void` und dem Namen \texttt{<init>}.
+\begin{lstlisting}[language=Java]
-Auf diese Weise müssen sie nicht mehr vom Typcheck oder vom Bytecode verändert werden.
+class TestClass {
-In Java ist es möglich mehrere Variablen in einer Zeile zu deklarieren (Bsp.: \texttt{int x, y;}).
+    int field;
-Beim Parsen ergiebt sich dann die Schwierigkeit, dass man in dem Moment, wo 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.
+    TestClass() {}
-In den darüberliegenden Regeln fielddeclaration und localvariabledeclaration wird dann die Typinformation hinzugefügt mithilfe der Funktion convertDeclarator.
+
-Für die Zuweisung wird auch die Kombination mit Rechenoperatoren unterstützt. Das Ganze ist als syntactic sugar im Parser umgesetzt.
+    void foo() {}
-Wenn es einen Zuweisungsoperator gibt, dann wird der Ausdruck in eine Zuweisung und Rechnung aufgeteilt.
+}
-Bsp.: \texttt{x += 3;} wird umgewandelt zu \texttt{x = x + 3}.
+\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.
+
+In Java ist es möglich mehrere Variablen in einer Zeile zu deklarieren (Bsp.: `int x, y;`). Beim Parsen ergiebt sich dann die Schwierigkeit, dass man in dem Moment, wo 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 fielddeclaration und localvariabledeclaration wird dann die Typinformation hinzugefügt mithilfe der Funktion convertDeclarator.
+
+\subsubsection{Syntactic Sugar}
+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 wurde 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}

src/Parser/JavaParser.y

@@ -386,7 +386,7 @@ multiplicativeexpression : unaryexpression { $1 }
 
 {
 
-data MethodOrFieldDeclaration = MethodDecl MethodDeclaration
+data MemberDeclaration = MethodDecl MethodDeclaration
                               | ConstructorDecl ConstructorDeclaration
                               | FieldDecls [VariableDeclaration]