Code: Alles auswählen
Macro XXX
YYY
.
EndMacro
Define *XXX
Code: Alles auswählen
Macro XXX
YYY
.
EndMacro
Define XXX$Code: Alles auswählen
Define *XXXCode: Alles auswählen
Define XXX$ 
Es ist verständlich, aber richtig ist es deswegen noch lange nicht. Aufgrund des Vorgängertokens würde sich eindeutig feststellen lassen, dass es sich bei *XXX um einen Token handelt. In Pb ist das Sternchen vor einem Pointer eben kein Adressoperator sondern ist Bestandteil des Variablennamens.Sicro hat geschrieben:Das ist schon richtig so, weil Macros Tokens ersetzen.
Macros werden auf Lexer-Ebene (betrachtet jedes Token separat) ersetzt und nicht auf Parser-Ebene (betrachtet die Konstellation von Tokens), darum ist keine eindeutige Feststellung möglich.Josh hat geschrieben:Aufgrund des Vorgängertokens würde sich eindeutig feststellen lassen, dass es sich bei *XXX um einen Token handelt.
Es ist vielleicht nicht die beste Verarbeitungsart, aber falsch ist es nicht.Josh hat geschrieben:aber richtig ist es deswegen noch lange nicht
Richtig. In dem Fall ist das "*"-Zeichen weder ein Operator noch ein Token und wird vom String-Token als normales Zeichen konsumiert. Bei Strings ist es aber auch einfach, weil der Lexer weiß, wo der String beginnt (beim öffnenden Anführungszeichen) und wo er aufhört (beim schließendem Anführungszeichen). Dazwischen wird jedes Zeichen konsumiert und als Teil des Strings interpretiert.#NULL hat geschrieben:Wenn das ganze innerhalb eines zuvor geöffneten Strings steht ist * ja auch kein Operator mehr.
#NULL hat geschrieben:Ob das zwei separate Tokens sind oder ob sie zu einem gehören hängt doch auch vom Kontext ab und nicht nur vom Zeichen.
Code: Alles auswählen
c=a*bWie oben schon geschrieben: Ein Lexer betrachtet keine Konstellationen von Tokens. Das macht der Parser.#NULL hat geschrieben:Selbst wenn im Fall von 'a=b*xxx' das 'b' ein Macro ist und zu 'x*' aufgelöst wird, dann ist der Kontext damit wieder klar und das zweite * kann dann kein Operator sein.
Nein, das ist sehr wohl die Aufgabe des Lexers. Ein Lexer ordnet den Tokens zu, ob es sich um einen Bezeichner, Operator, Literal, Trennzeichen oder sonst was handelt. Da 'a' nur ein Bezeichner sein kann, kann kein weiterer Bezeichner folgen und somit ist das '*' ein Operator und 'b' in weiterer Folge wieder ein Bezeichner.Sicro hat geschrieben:Wie willst du bei dem obigem Code ermitteln, ob "*b" ein Pointer-Variable-Token oder ein Operator-Token ist, ohne zu prüfen, ob "a" ein Variable-Token ist (Aufgabe des Parsers, nicht des Lexers)?Code: Alles auswählen
c=a*b
Ein Lexer prüft keine vorherigen oder nachfolgenden Tokens. Er arbeitet überhaupt nicht mit Tokens, sondern erstellt sie nur, und zwar aus Zeichenfolgen, die einem bestimmtem Muster verlaufen.Josh hat geschrieben:Nein, das ist sehr wohl die Aufgabe des Lexers.
Korrekt. Ich behaupte, aber nirgends was anderes.Josh hat geschrieben:Ein Lexer ordnet den Tokens zu, ob es sich um einen Bezeichner, Operator, Literal, Trennzeichen oder sonst was handelt.
Dem Lexer ist es egal, ob die Syntax des Codes stimmt oder nicht. Er erstellt einfach die Tokens, ohne irgendetwas Weiteres zu prüfen. Das, was du im Zitat schreibst, prüft der Parser, nicht der Lexer.Josh hat geschrieben:Da 'a' nur ein Bezeichner sein kann, kann kein weiterer Bezeichner folgen und somit ist das '*' ein Operator und 'b' in weiterer Folge wieder ein Bezeichner.
Es ist nicht so üblich, dass Lexer bei Leerzeichen Tokens erstellen, aber ausgeschlossen ist es nicht.Josh hat geschrieben:Alles andere wäre auch widersinnig. Der Parser könnte z.B. nicht mehr erkennen, dass bei 'a = b + * c' ein Syntax-Fehler auszugeben ist, da der Parser von Leerzeichen/Tabs nichts mehr weiß.