Packagenamen - Grundsätzliches Problem #186

New Issue

pl · 2016-05-05T11:31:58Z

pl commented

2016-05-05 11:31:58 +00:00

im Moment ist das Problem, dass bei importierten Paketen (z.B. java.util.Vector) nicht festgelegt ob mit dem qualifizierten Namen oder ohne unifiziert wird.
z.B. wird java.util.Vector<java.util.Vector> als Vector<java.util.Vector> im FC in die Unifikation gegeben.
Das muss grundsätzlich geklärt werden.

Vorschlag: Wir arbeiten mit qualifizierten Namen. D.h.:
Vector<Vector> wird nach dem Parsen in java.util.Vector<java.util.Vector<java.lang.Integer>> umgewandelt.

im Moment ist das Problem, dass bei importierten Paketen (z.B. java.util.Vector) nicht festgelegt ob mit dem qualifizierten Namen oder ohne unifiziert wird. z.B. wird java.util.Vector<java.util.Vector<X>> als Vector<java.util.Vector<X>> im FC in die Unifikation gegeben. Das muss grundsätzlich geklärt werden. Vorschlag: Wir arbeiten mit qualifizierten Namen. D.h.: Vector<Vector<Integer>> wird nach dem Parsen in java.util.Vector<java.util.Vector<java.lang.Integer>> umgewandelt.

stan commented

2016-05-06 13:46:47 +00:00

Ich hab das mal versucht umzubauen, dass nur noch die qualifizierten Namen verwendet werden.
Das Problem ist hier der Aufbau, wie der Sourcecode momentan von unserem Compiler eingelesen wird.
Meiner Meinung nach sollte im Parserschritt einfach mehr passieren. Bisher macht der Parser eben ausschließlich parsen und liefert nur mäßig nützlichen Output.
Er erkennt Generische Variablen nicht, er erkennt den Konstruktor nicht, er löst die Typbezeichnungen nicht mit ihrem vollen Qualifizierten Namen auf, etc.
Daher hab ich mal so ein "parserPostProcessing" gebastelt.
Problem ist, dass bei diesem Schritt das TypeAssumption-Set noch nicht feststeht. Dieses wird gebraucht um beispielsweise Vector zu java.util.Vector aufzulösen.
Momentan werden daher die Namen erst während der TYPE Methode aufgelöst. Die FC wird aber noch vor der TYPE Methode erstellt. Dein Problem kann man wohl beheben, indem man die FC erst vor der Unifizierung erstellt.
Ein Grundsätzliches Problem bleibt, nämlich der verkorkste Workflow unserer Compilers, der momentan folgendermaßen aussieht:

Parsen
parserPostProcessing
TypeAssumptions bauen
TYPE
Namen auflösen und kontrollieren ob es die Typen wirklich im Scope gibt
Unify
...
Profit

Mein Vorschlag wäre (falls wirklich mal jemand das ANTLR-Parserprojekt in Angriff nimmt) die Punkte 1, 2, 3 und 5 alle in den Parser und das anschließende abstrakte Syntaxbaum Bauen zu verschieben. Dann passieren vielleicht auch solche Fehler nicht mehr.

Ich hab das mal versucht umzubauen, dass nur noch die qualifizierten Namen verwendet werden. Das Problem ist hier der Aufbau, wie der Sourcecode momentan von unserem Compiler eingelesen wird. Meiner Meinung nach sollte im Parserschritt einfach mehr passieren. Bisher macht der Parser eben ausschließlich parsen und liefert nur mäßig nützlichen Output. Er erkennt Generische Variablen nicht, er erkennt den Konstruktor nicht, er löst die Typbezeichnungen nicht mit ihrem vollen Qualifizierten Namen auf, etc. Daher hab ich mal so ein "parserPostProcessing" gebastelt. Problem ist, dass bei diesem Schritt das TypeAssumption-Set noch nicht feststeht. Dieses wird gebraucht um beispielsweise Vector zu java.util.Vector aufzulösen. Momentan werden daher die Namen erst während der TYPE Methode aufgelöst. Die FC wird aber noch vor der TYPE Methode erstellt. Dein Problem kann man wohl beheben, indem man die FC erst vor der Unifizierung erstellt. Ein Grundsätzliches Problem bleibt, nämlich der verkorkste Workflow unserer Compilers, der momentan folgendermaßen aussieht: 1. Parsen 2. parserPostProcessing 3. TypeAssumptions bauen 4. TYPE 5. Namen auflösen und kontrollieren ob es die Typen wirklich im Scope gibt 6. Unify 7. ... 8. Profit Mein Vorschlag wäre (falls wirklich mal jemand das ANTLR-Parserprojekt in Angriff nimmt) die Punkte 1, 2, 3 und 5 alle in den Parser und das anschließende abstrakte Syntaxbaum Bauen zu verschieben. Dann passieren vielleicht auch solche Fehler nicht mehr.

stan commented

2016-05-12 19:45:42 +00:00

*** Bug 47 has been marked as a duplicate of this bug. ***