forked from JavaTX/JavaCompilerCore
131 lines
4.4 KiB
Plaintext
Executable File
131 lines
4.4 KiB
Plaintext
Executable File
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
|