Allgemein:
==========

LineNumber:
===========

Hinzugefügt zu den Klassen:

- Method
- DeclId

Methode "getTypeLineNumber()" zu allen TypeReplacementListenern hinzugefügt.

NichtterminalRegeln:

- methoddeclarator
- variabledeclaratorid


TyploseVariable vs. Generics:
=============================

Bisher wird kein Unterschied zwischen generischen Typvariablen (bsp.: "class<A>") und typlosen Variablen
(bsp.: "public void(para1)") gemacht. Für beide Fälle wird eine Instanz der Klasse "TyploseVariable" angelegt.

Dies wird geändert: Es gibt ab jetzt eine Unterklasse von "Type" namens "GenericTypeVar".

TyploseVariable:
================
Eine Typlose Variable kann ab jetzt nicht mehr direkt erzeugt werden. Der Konstruktor ist nun private!
Um eine neue TyploseVariable zu erhalten, muss die statische Methode TyploseVariable.fresh() aufgerufen werden.
Ansonsten kann über die statische Methode  TyploseVariable.getInstance(String) eine bestimmte TyploseVariable
geholt werden.

Zum abstrakten Syntaxbaum:
==========================

Der Typrekonstruktionsalgorithmus manipuliert den Syntaxbaum nicht. Es wird nur lesend auf den Syntaxbaum
zugegriffen, ansonsten ist der Algorithmus losgelöst vom Syntaxbaum.
Die einzige Aufgabe des Algorithmus ist, die korrekten Typangaben herauszufinden. Erst nach erfolgreicher
Ausführung des Algorithmus, werden die Typen ersetzt. Dies geschieht über die TypeReplacementListener, die
die einzige Verbindung zwischen der Algorithmusdatenstruktur (TypeAssumptions und Substitutions) und der
Datenstruktur des abstrakten Syntaxbaumes darstellt.

So kann die Algorithmusdatenstruktur munter geklont werden, solange nur immer die TyploseVariable-Referenzen
korrekt, d.h. in diesem Falle flach, kopiert werden. So zeigen am Ende alle Typannahmemöglichkeiten auf dieselben
Elemente des Syntaxbaumes, aber nur die vom User ausgewählte Lösung manipuliert den Syntaxbaum.

ITypeReplacementListener:
=========================

InstVarDecl
LocalVarDecl
FormalParameter
Method

eventuell noch:

CastExpr - Nicht! hier kommt nie ne TyploseVariable rein!
ExprStmt
NewArray - Nein!


Zur Substitution:
=================

Die Klasse CSubstitution kapselt zwei Typreferenzen, wobei eine davon eine Typlose Variable ist.
Um während des Typrekonstruktionalgorithmus eine Substitution auf die Menge der Typannahmen auszuführen,
steht die Methode CTypeAssumptionSet.sub() zur Verfügung, die dem Algorithmus sub() aus Martins Paper
entspricht.

Um jedoch die letztendliche Substitution auf dem abstrakten Syntaxbaum durchzuführen, muss die Methode
CSubstitution.execute() aufgerufen werden. Dies sollte erst über die GUI der IDE ausgelöst werden und
nicht Teil des TypRekonstruktionsalgorithmus sein.

Zusammenfassung:
================

Substitutionen bzw. die Anwendung von Unifiern findet also letztendlich auf 3 Ebenen statt bzw. arbeitet
auf 3 unterschiedlichen Datenstrukturen:

	1. Auf den Mengen von Typannahmen über die Methode "sub()"
	2. Auf den Mengen von bereits ermittelten Substitutionen über die Methode "applyUnifier()"
	3. Ganz am Ende auf dem abstrakten Syntaxbaum über die Methode "execute()"


Was ich getan habe:
===================

- Projekt neu strukturiert
- MyCompiler neu strukturiert
- TypeAssumption-Datenstrukturen erstellt
- TypeReplacementListener implementiert
- TyploseVariable modifiziert
- GenericTypeVar eingeführt
- Compiler-Schnittstelle definiert
- TRProg implementiert
- TRStart implementiert
- TRNextMethod implementiert
- CSupportData erstellt
- Jay-File angepasst:
	- TyploseVariable eingeführt
	- GenericTypeVar eingeführt
	- Diverse Fehler beseitigt:
		- Void
		- TyploseVariable.setName()
- Klassen BoolLiteral, CharLiteral und IntLiteral geändert ==> BaseTypes eingeführt

Was Martin gemacht hat:
=======================

- Unify-Algorithmus angepasst
- Unify statisch gemacht und Klasse Unify erstellt


Ungelöste Probleme:
===================

- Unterscheidung von RefTypes und GenericTypeVars beim Parsen bzw. während des Typrekonstruktionsalgorithmus
- Umwandlung von GenericTypeVars nach Durchlaufen des Algorithmus ==> Kopplung mehrerer parametrisierter Klassen
- Anpassung des Algorithmus auf dem Papier der Art, dass alle Substitutionen nach oben mitgegeben werden ==> siehe Implementierung
- Unterstützung von BaseTypes
- Einführung eines echten IntersectionTypes
- Shift-Reduce-Konflikte im Jay-File

Was (noch) nicht unterstützt wird:
==================================

- Arrays
- Mehrere Klassen