PureBoard

Sicro hat geschrieben:

Josh hat geschrieben:Nein, das ist sehr wohl die Aufgabe des Lexers.

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.
Der Parser verarbeitet danach nur noch die Tokens und keine einzelnen Zeichen mehr.

Sicro hat geschrieben:

Josh hat geschrieben:Ein Lexer ordnet den Tokens zu, ob es sich um einen Bezeichner, Operator, Literal, Trennzeichen oder sonst was handelt.

Korrekt. Ich behaupte, aber nirgends was anderes.

Sicro hat geschrieben:

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.

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.

Sicro hat geschrieben:

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ß.

Es ist nicht so üblich, dass Lexer bei Leerzeichen Tokens erstellen, aber ausgeschlossen ist es nicht.
Hier kannst du es nachlesen: https://en.wikipedia.org/wiki/Lexical_analysis
Die deutsche Version des Wikipedia-Artikels ist leider nicht so umfangreich beschrieben.
In dem Wikipedia-Artikel findest du die relevanten Textstellen, wenn die Textsuchfunktion des Browsers mit "whitespace" fütterst.

[bezeichner_a] [operator_=] [bezeichner_b] [operator_+] [operator_*] [leerzeichen] [bezeichner_c]
"c" ist somit keine Pointer-Variable, weil zwischen "*" und Bezeichner kein Leerzeichen sein darf.
Zwischen den anderen Tokens können natürlich ebenfalls Leerzeichen-Tokens sein, habe ich jetzt aber der einfachheitshalber mal weggelassen, weil der Parser selber entscheiden kann, ob er das Leerzeichen-Token an dieser Position berücksichtigt oder ignoriert.

Josh hat geschrieben:Ein Lexer kann durchaus auf den vorhergehenden Token zurückblicken oder auf das folgende Zeichen

Sicro hat geschrieben: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.
Der Parser verarbeitet danach nur noch die Tokens und keine einzelnen Zeichen mehr.

Josh hat geschrieben:Das einzige was in diesem Zusammenhang relevant ist, ist dein erster Satz und das ist falsch.

Josh hat geschrieben:Ein Lexer kann durchaus auf den vorhergehenden Token zurückblicken oder auf das folgende Zeichen (ein folgender Token ist ja noch nicht erstellt, ein Beispiel in Pb wäre das Tilde-Zeichen) vorausschauen und daraus Rückschlüsse ziehen.

Wikipedia hat geschrieben:A lexical analyzer generally does nothing with combinations of tokens, a task left for a parser.

Wikipedia hat geschrieben:Generally lexical grammars are context-free, or almost so, and thus require no looking back or ahead, or backtracking, which allows a simple, clean, and efficient implementation. This also allows simple one-way communication from lexer to parser, without needing any information flowing back to the lexer.

Wikipedia hat geschrieben:When a token class represents more than one possible lexeme, the lexer often saves enough information to reproduce the original lexeme, so that it can be used in semantic analysis. The parser typically retrieves this information from the lexer and stores it in the abstract syntax tree.

Josh hat geschrieben:Weiter unten hast du einen Link auf einen Wiki-Artikel gesetzt, ich empfehle dir, diesen auch zu lesen.

Josh hat geschrieben:Ja, aber wenn du einem Token einen Tokentyp zuordnest, dann solltest du es richtig machen und nicht (wie von dir weiter unten angegeben) das Sternchen einfach als Operator kennzeichnen, obwohl so ca. eine 50/50 Chance besteht, dass es falsch ist.

Josh hat geschrieben:Nochmals, das Sternchen bei einem Pointer ist in Pb Bestandteil des Bezeichners[...] '*AnyPointer' ist EIN Token.

; stringVariable$  = "string"
  MOV    rsi,_S1
  LEA    rdi,[v_stringVariable$]
  CALL   SYS_FastAllocateStringFree4
; *pointerVariable = 0
  MOV    qword [p_pointerVariable],0
; integerVariable  = 123
  MOV    qword [v_integerVariable],123
; quadVariable     = 456
  MOV    qword [v_quadVariable],456

Nino hat geschrieben:Für mich ist es klar ein Bug im Makro-Preprocessor.

Wikipedia hat geschrieben:There are exceptions, however. Simple examples include: semicolon insertion in Go, which requires looking back one token; concatenation of consecutive string literals in Python,[10] which requires holding one token in a buffer before emitting it (to see if the next token is another string literal); and the off-side rule in Python, which requires maintaining a count of indent level (indeed, a stack of each indent level). These examples all only require lexical context, and while they complicate a lexer somewhat, they are invisible to the parser and later phases.

Sicro hat geschrieben:

Nino hat geschrieben:Für mich ist es klar ein Bug im Makro-Preprocessor.

In der PB-Hilfe steht bei der Macro-Beschreibung nichts darüber, das Macros Namen von Variablen ersetzen (nehmen wir hier mal an, "*" wäre Bestandteil des Variable-Namens), sondern das der Macro-Name (Macro-Aufruf) durch den Macro-Inhalt ersetzt wird.

Macro XXX
  YYY
  .
EndMacro

Define aXXX      ; Zeile 6
Define *XXX

Sicro hat geschrieben:Wie einleitend geschrieben wird sind das aber Ausnahmen und nicht das normale Vorgehen von einem Lexer.

Nino hat geschrieben:Es ist ja gerade der Zweck des Lexers, den Input in einzelne Tokens aufzuteilen. Dazu muss er natürlich auch in jedem Einzelfall "entscheiden", ob * ein separates Token ist (Operator) oder der Beginn eines Bezeichners. Macht ein Lexer das nicht, so erfüllt er seine Aufgabe nicht.

Aus praktischer Sicht: Da es nunmal diese beiden Möglichkeiten für * in PureBasic gibt, muss PureBasic auch insgesamt korrekt damit umgehen können -- nicht nur der Compiler.

Nino hat geschrieben:

Sicro hat geschrieben:

Nino hat geschrieben:Für mich ist es klar ein Bug im Makro-Preprocessor.

In der PB-Hilfe steht bei der Macro-Beschreibung nichts darüber, das Macros Namen von Variablen ersetzen (nehmen wir hier mal an, "*" wäre Bestandteil des Variable-Namens), sondern das der Macro-Name (Macro-Aufruf) durch den Macro-Inhalt ersetzt wird.

Ja und

ReplaceString(codeNachdemMacroDefinitionBlock$, macroName$, macroInhalt$)

*XXX => *YYY
XXX$ => YYY$

Nino hat geschrieben:Der Makro-Name soll nur an den Stellen im Quelltext durch den Makro-Inhalt ersetzt werden, an denen er als eigenständiges Token auftaucht.
Deshalb wird auch im folgenden Code

Code: Alles auswählen

Macro XXX
  YYY
  .
EndMacro

Define aXXX      ; Zeile 6
Define *XXX 

in Zeile 6 der Makro-Name richtigerweise nicht durch den Makro-Inhalt ersetzt. Und in Zeile 7 sollte es ebenfalls nicht geschehen. Es passiert aber doch, das ist der Bug.

Wikipedia hat geschrieben:There are exceptions, however. Simple examples include: semicolon insertion in Go, which requires looking back one token; concatenation of consecutive string literals in Python,[10] which requires holding one token in a buffer before emitting it (to see if the next token is another string literal); and the off-side rule in Python, which requires maintaining a count of indent level (indeed, a stack of each indent level). These examples all only require lexical context, and while they complicate a lexer somewhat, they are invisible to the parser and later phases.

Sicro hat geschrieben:Wie einleitend geschrieben wird sind das aber Ausnahmen und nicht das normale Vorgehen von einem Lexer.

Nino hat geschrieben:Was Ausnahmen sind und was nicht ist eine Frage der Statistik, darum geht es hier überhaupt nicht. Wenn eine Situation eintritt, in welcher der Lexer zunächst nicht "weiß" welches Zeichen zu welchem Token gehört, so muss er halt Schritte unternehmen, um das herauszufinden. Was hat das damit zu tun wie häufig so eine Situation eintritt? Gar nichts.

Macro BinaryNumber
  101
EndMacro

Macro HexNumber
  A
EndMacro

Macro Identifier
  TestIdentifier
EndMacro
Macro Identifier2
  TestIdentifier2
EndMacro

Debug %BinaryNumber
Debug $HexNumber

Identifier$ = "StringVariable: Ein Test"
Debug TestIdentifier$

*Identifier = 123
Debug *TestIdentifier

;#Identifier = "Constant: Ein Test"
;Debug #TestIdentifier

Procedure Identifier()
  Debug "Procedure: Ein Test"
EndProcedure
TestIdentifier()

Structure TestStruc
  Array Identifier.i(0)
  Identifier2.i[1]
EndStructure
Test.TestStruc
Test\TestIdentifier(0)  = 123
Test\TestIdentifier2[0] = 456
Debug Test\TestIdentifier(0)
Debug Test\TestIdentifier2[0]

asmPointerVariableName$ = ReplaceString(originalPointerVariableName$, "*", "p_")