Bedienung > Hauptmenü > Menü: Einstellungen > Projekteinstellungen > Parser/Scanner > Globaler Scanner
Auf der Seite "Parser/Scanner" der Projektoptionen gibt es drei Checkboxen durch die eine Feinjustierung der Scan-Prozesses vorgenommen werden kann.
Es wird empfohlen, die Default-Einstellungen beizubehalten. wenn man nicht die folgenden Ausführungen studieren will und spezielle Gründe findet, sie zu ändern. Als Standard ist nur die Verwendung des globalen Scanners für Literale aktiviert.
Die Pufferung der Vorausschau-Token kann die Ausführung eines Projektes beschleunigen, wenn in ihm von der Möglichkeit zur Vorausschau starker Gebrauch gemacht wird. Meist ist dies nicht der Fall.
Die anderen Einstellungen in dieser Box dienen der Kontrolle der Tokenmengen, die jeweils an der aktuellen Stelle der Grammatik getestet werden. Dadurch werden die Geschwindigkeit des Parsers und die Fehlerwahrscheinlichkeit beeinflusst. Größere Tokenmengen verlangsamen den Parser und erhöhen die Wahrscheinlichkeit, dass ein Token ermittelt wird, dass nicht zur Grammatik passt. Letzteres kann in bestimmten Fällen durchaus gewünscht sein.
Werden keine globalen Scanner verwendet, so wird beim Parsen - mit lokalen Scannern - immer nur nach den Token gesucht die gemäß der Grammatik aktuell folgen können Hingegen, wenn globale Scanner verwendet werden, so kann immer auf alle Literale getestet werden und auch immer auf alle regulären Ausdrücke getestet werden oder auch nur dann alle getestet werden, wenn überhaupt ein Literal/regulärer Ausdruck erwartet wird.
Anmerkung: Intern gibt es noch einen dritten Scanner, der lokal oder global sein kann: der Scanner für die auszulassenden Zeichen. Ob dieser Scanner lokal oder global ist, wird dadurch bestimmt, ob die auszulassenden Zeichen, in den lokalen Optionen gegenüber den globalen verändert sind oder nicht.
Etwas ausführlicher das Gleiche nochmal:
Den drei Scannertypen entsprechen drei Schritte, die bei der Ermittlung des jeweils nächsten Tokens durchgeführt werden. Ausgehend von der aktuellen Position im Quelltext wird geprüft,
1. ob auszulassende Zeichen folgen, dann
2. ob hierauf ein literales Token folgt oder,
3. ob ein mittels eines regulären Ausdrucks definiertes Token folgt
Diese drei Tests können entweder durch einen einzelnen globalen Scanner durchgeführt werden oder durch lokale Scanner. Die Verwendung eines globalen Scanners ist die traditionelle Methode, die bei allen bisherigen Parsergeneratoren angewendet wurde. Die Verwendung von lokalen Scannern beruht auf der Idee, dass zur Ermittlung des nächsten Tokens, nur diejenigen Kandidaten geprüft werden müssen, die tatsächlich zur aktuellen Alternative gehören. Zum Testen der folgenden Struktur beispielsweise ist es zunächst nur erforderlich zu entscheiden, ob ein a- oder ein b-Token an der aktuellen Textposition vorkommt.
( a | b ) c d
Ein lokaler Scanner testet daher genau dies. Ein traditioneller globaler Scanner hingegen prüft auf alle Token der Grammatik, also mindestens das a-, b-, c- und d-Token. Das Ergebnis ist in diesem Beispiel für beide Scannertypen identisch. Der Unterschied liegt in der Geschwindigkeit und dem Aufwand. Bei Verwendung lokaler Scanner ist die Geschwindigkeit des Scanprozesses gegenüber der der traditionellen Methode größer. Erkauft wird dieser Vorteil durch einen größeren Speicherbedarf der Menge an lokalen Scanner gegenüber dem Bedarf eines einzelnen globalen Scanners.
Auch das Ergebnis der Textanalyse kann durch die Wahl globaler bzw. lokaler Scanner beeinflusst werden. Bei Verwendung eines globalen Scanners ist die Wahrscheinlichkeit, das es Konflikte zwischen einzelnen Token gibt größer als bei Verwendung lokaler Scanner, in denen jeweils nur eine kleinere Anzahl von Token zueinander in Konkurrenz stehen. Dies ist der Grund dafür, warum es die zusätzliche Möglichkeit gibt, das Testen auf die aktuell erwarteten Token einzuschränken, auch wenn ein globaler Scanner für Literale verwendet wird.
Beispiel:
Text: "int int"
Produktion: "int" ID
Token ID: \w+
Wenn stets alle literalen Token getestet werden, wird das zweite Vorkommen von "int" nicht als ID erkannt. Es wird vielmehr erneut das literale Token "int" erkannt. Der Text kann also nicht geparst werden. Dies ist erwünscht, wenn der Text einen C++-Code darstellen soll. Eine Variable darf nicht den Namen eines Variablen-Typs haben.
Text: "Herr Herr"
Produktion: "Herr" NAME
Token NAME: \w+
Schauen sie ins Telefonbuch, und sie werden den Namen "Herr" darin finden. Die Anrede "Herr Herr" ist also durchaus korrekt. Sie wird nur erkannt, wenn nicht auf alle literalen Token getestet wird.
Faustregel:
Alle Literale sollten getestet werden, falls eine formalisierte Sprachen mit definierten Schlüsselworten, die an ausgezeichneten Positionen stehen, geparst werden soll. Andernefalls sollten nur die erwarteten Literale getestet werden. Nötigenfalls können auch die lokalen Optionen jeweils angepasst werden.
(Ein analoges Beispiel ist die SemText-Regel im CC2TT-Projekt.)
Konflikte, die durch die Verwendung eines globalen Scanners verursacht sind, können zur Laufzeit folgende Fehlermeldung hervorrufen:
Passendes aber nicht akzeptiertes Token: ...
Bei der Beschreibung dieser Meldung ist auch ein Beispiel angeführt.
Bei der Erläuterung der Vorausschau Produktionen wird ein weiteres Beispiel für die Auswirkungen der Scanner Optionen gegeben.