-> Hier kostenlos registrieren
Ich starte hiermit den Thread für Themen rund um den Parser.
Gruß Barnee
Gruß Barnee
Themen zum Parser
- Ersteller Barnee
- Erstellt am
-> Hier kostenlos registrieren
Erste Schritte zum Bau des Parsers
Wie bereits im Themenkreis zu dem PP erläutert wurde, gehe ich davon aus, dass alle für die Wirkung des Parsers notwendigen Informationen sich in dynamisch angelegten Speicherbereichen befinden. Der PP stellt dem Parser, wie schon früher dargestellt und wie in der Folge im Themenkreis zum PP noch weiter ausgeführt werden wird, stellt der PP dem Parser einen aufbereiteten C-Quelltext zur Verfügung.
Wie der PP arbeitet auch der Parser ausschließlich mit dynamisch reserviertem Speicher.
Zu diesem Zeitpunkt verfügt der Parser über Informationen, die den Bezug zu dem ursprünglichen Quelltext herstellen. Das ist wie auch beim PP notwendig, um mögliche Fehlerausschriften mit dem Bezug auf den ursprünglichen Quelltext herstellen zu können.
Die Frage, ob der Parser seine Arbeit aufnimmt, wenn bei der Ausführung des PPs schon Fehler festgestellt wurden, muss im PP abgehandelt? <--- Diskussionspunkt!!!
Hier hinter verbirgt sich die Absicht, selbst bei Fehlern den Compilerlauf solange wie möglich fortzusetzen. Ich kenne aus früheren Zeiten den Pascal-Compiler von Think, der bei dem ersten Auftauchen eines Fehlers seine Arbeit schon unterbrochen hat, das wäre mehr als lästig!
Ich stelle mir vor, dass vor dem Start des Parsers mindestens diese Informationen vorliegen sollten - also Informationen, die vom PP ermittelt wurden:
- alle Makros wurden substituiert;
- alle Variablen-Referenzen ermittelt;
- alle in einem Baustein aufgerufene Funktionen;
- alle Klammerungen {}, () oder [] sind formal auf Abschluss geprüft worden, formal heißt hier lediglich, dass alle geöffneten Klammern auch geschlossen sein müssen. Eine verbotene Schachtelung unterschiedlicher Klammertypen sollte auch schon erkannt sein, also eine {-Klammer kann nicht durch eine ]-Klammer geschlossen werden usw.usf.
Es drängt sich mir die Frage auf, welcher Teil - PP oder Parser - schon mit einer Vorabprüfung des Typs beauftragt werden sollte, ein Beispiel:
Wenn "b" oder "c" oder beide nicht vom Typ Boolean sind, dann lässt sich dieser Ausdruck nicht auflösen. Ich bin mir im Augenblick nicht sicher, ob zu jedem Zeitpunkt des PPs, auch alle dazu notwendigen Informationen vorliegen. Schauen wir uns dieses Beispiel an:
Wenn z.B. "x" und "y" den Typ Float besitzen aber "z" vom Typ Integer (egal ob short oder long) ist, dann wird implizit eine Typwandlung vorausgesetzt und eine Typprüfung darf nicht zum Fehler führen.
Fortsetzung folgt, Diskussion erbeten.
Gruß Barnee
Wie bereits im Themenkreis zu dem PP erläutert wurde, gehe ich davon aus, dass alle für die Wirkung des Parsers notwendigen Informationen sich in dynamisch angelegten Speicherbereichen befinden. Der PP stellt dem Parser, wie schon früher dargestellt und wie in der Folge im Themenkreis zum PP noch weiter ausgeführt werden wird, stellt der PP dem Parser einen aufbereiteten C-Quelltext zur Verfügung.
Wie der PP arbeitet auch der Parser ausschließlich mit dynamisch reserviertem Speicher.
Zu diesem Zeitpunkt verfügt der Parser über Informationen, die den Bezug zu dem ursprünglichen Quelltext herstellen. Das ist wie auch beim PP notwendig, um mögliche Fehlerausschriften mit dem Bezug auf den ursprünglichen Quelltext herstellen zu können.
Die Frage, ob der Parser seine Arbeit aufnimmt, wenn bei der Ausführung des PPs schon Fehler festgestellt wurden, muss im PP abgehandelt? <--- Diskussionspunkt!!!
Hier hinter verbirgt sich die Absicht, selbst bei Fehlern den Compilerlauf solange wie möglich fortzusetzen. Ich kenne aus früheren Zeiten den Pascal-Compiler von Think, der bei dem ersten Auftauchen eines Fehlers seine Arbeit schon unterbrochen hat, das wäre mehr als lästig!
Ich stelle mir vor, dass vor dem Start des Parsers mindestens diese Informationen vorliegen sollten - also Informationen, die vom PP ermittelt wurden:
- alle Makros wurden substituiert;
- alle Variablen-Referenzen ermittelt;
- alle in einem Baustein aufgerufene Funktionen;
- alle Klammerungen {}, () oder [] sind formal auf Abschluss geprüft worden, formal heißt hier lediglich, dass alle geöffneten Klammern auch geschlossen sein müssen. Eine verbotene Schachtelung unterschiedlicher Klammertypen sollte auch schon erkannt sein, also eine {-Klammer kann nicht durch eine ]-Klammer geschlossen werden usw.usf.
Es drängt sich mir die Frage auf, welcher Teil - PP oder Parser - schon mit einer Vorabprüfung des Typs beauftragt werden sollte, ein Beispiel:
Code:
a = b || c;Wenn "b" oder "c" oder beide nicht vom Typ Boolean sind, dann lässt sich dieser Ausdruck nicht auflösen. Ich bin mir im Augenblick nicht sicher, ob zu jedem Zeitpunkt des PPs, auch alle dazu notwendigen Informationen vorliegen. Schauen wir uns dieses Beispiel an:
Code:
x = y + z;Wenn z.B. "x" und "y" den Typ Float besitzen aber "z" vom Typ Integer (egal ob short oder long) ist, dann wird implizit eine Typwandlung vorausgesetzt und eine Typprüfung darf nicht zum Fehler führen.
Fortsetzung folgt, Diskussion erbeten.
Gruß Barnee
