forked from JavaTX/JavaCompilerCore
131 lines
4.4 KiB
Plaintext
131 lines
4.4 KiB
Plaintext
|
Allgemein:
|
|||
|
|
==========
|
|||
|
|
|
|||
|
|
LineNumber:
|
|||
|
|
===========
|
|||
|
|
|
|||
|
|
Hinzugef<EFBFBD>gt zu den Klassen:
|
|||
|
|
|
|||
|
|
- Method
|
|||
|
|
- DeclId
|
|||
|
|
|
|||
|
|
Methode "getTypeLineNumber()" zu allen TypeReplacementListenern hinzugef<65>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<67>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 <20>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<65>st vom Syntaxbaum.
|
|||
|
|
Die einzige Aufgabe des Algorithmus ist, die korrekten Typangaben herauszufinden. Erst nach erfolgreicher
|
|||
|
|
Ausf<EFBFBD>hrung des Algorithmus, werden die Typen ersetzt. Dies geschieht <20>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<65>glichkeiten auf dieselben
|
|||
|
|
Elemente des Syntaxbaumes, aber nur die vom User ausgew<65>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<75>hren,
|
|||
|
|
steht die Methode CTypeAssumptionSet.sub() zur Verf<72>gung, die dem Algorithmus sub() aus Martins Paper
|
|||
|
|
entspricht.
|
|||
|
|
|
|||
|
|
Um jedoch die letztendliche Substitution auf dem abstrakten Syntaxbaum durchzuf<75>hren, muss die Methode
|
|||
|
|
CSubstitution.execute() aufgerufen werden. Dies sollte erst <20>ber die GUI der IDE ausgel<65>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 <20>ber die Methode "sub()"
|
|||
|
|
2. Auf den Mengen von bereits ermittelten Substitutionen <20>ber die Methode "applyUnifier()"
|
|||
|
|
3. Ganz am Ende auf dem abstrakten Syntaxbaum <20>ber die Methode "execute()"
|
|||
|
|
|
|||
|
|
|
|||
|
|
Was ich getan habe:
|
|||
|
|
===================
|
|||
|
|
|
|||
|
|
- Projekt neu strukturiert
|
|||
|
|
- MyCompiler neu strukturiert
|
|||
|
|
- TypeAssumption-Datenstrukturen erstellt
|
|||
|
|
- TypeReplacementListener implementiert
|
|||
|
|
- TyploseVariable modifiziert
|
|||
|
|
- GenericTypeVar eingef<65>hrt
|
|||
|
|
- Compiler-Schnittstelle definiert
|
|||
|
|
- TRProg implementiert
|
|||
|
|
- TRStart implementiert
|
|||
|
|
- TRNextMethod implementiert
|
|||
|
|
- CSupportData erstellt
|
|||
|
|
- Jay-File angepasst:
|
|||
|
|
- TyploseVariable eingef<65>hrt
|
|||
|
|
- GenericTypeVar eingef<65>hrt
|
|||
|
|
- Diverse Fehler beseitigt:
|
|||
|
|
- Void
|
|||
|
|
- TyploseVariable.setName()
|
|||
|
|
- Klassen BoolLiteral, CharLiteral und IntLiteral ge<67>ndert ==> BaseTypes eingef<65>hrt
|
|||
|
|
|
|||
|
|
Was Martin gemacht hat:
|
|||
|
|
=======================
|
|||
|
|
|
|||
|
|
- Unify-Algorithmus angepasst
|
|||
|
|
- Unify statisch gemacht und Klasse Unify erstellt
|
|||
|
|
|
|||
|
|
|
|||
|
|
Ungel<EFBFBD>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<73>tzung von BaseTypes
|
|||
|
|
- Einf<6E>hrung eines echten IntersectionTypes
|
|||
|
|
- Shift-Reduce-Konflikte im Jay-File
|
|||
|
|
|
|||
|
|
Was (noch) nicht unterst<73>tzt wird:
|
|||
|
|
==================================
|
|||
|
|
|
|||
|
|
- Arrays
|
|||
|
|
- Mehrere Klassen
|