Dieser Scanner kann eine Zeichenkette, in der alle Terminalsymole T folgender Grammatik SG in beliebiger Reihenfolge vorkommen dürfen, tokenweise lesen.

Zur Entwicklung eines Scanners benötigt man generell nur die Definition der textuellen Zusammensetzung aller Terminalsymbole T einer Grammatik, nichts weiter! Die anderen Elemente einer Grammatik N, P und S haben nichts mit dem Scanner zu tun. Der Scanner „konzentriert” sich lediglich auf das tokenweise Lesen. Beim Lesen einer unbekannten Fremdsprache, verhält sich der Mensch wie ein Scanner, er liest wortweise, ohne etwas von der Grammatik zu wissen. Tokens sind fast wie Hieroglyphen, jede Hieroglyphe besitzt eine Bedeutung, die textuell ausgedrückt werden kann.

Da die Hauptarbeit eines Scanners darin liegt, einen Zeichenstrom in einen Tokenstrom umzuwandeln, benötigt man Tokens; es sind zumindest die Terminalsymbole der Grammatik. Hier werden die Tokens als Integer−Konstanten repräsentiert.

Hierbei kommt es vor allem darauf an, den Tokens sprechende Bezeichnungen (mnemonisch) zu geben. Welche Wertigkeit sich nun hinter einem Tokenbezeichner verbirgt, ist eigentlich egal. Letztendlich müssen die Tokens paarweise unterscheidbar sein. Um sicherzustellen, dass sich alle aufgeführten Tokens paarweise unterscheiden, können die Tokens auch nach dem Prinzip der Aufzählung deklariert werden:

... public static final int UNKNOWN = 0; public static final int EOS = UNKNOWN + 1; public static final int LPAREN1 = EOS + 1; public static final int RPAREN1 = LPAREN1 + 1; ...

Der Scanner würde somit leichter zu warten sein. Neue Tokens können einfach in die Aufzählung eingegliedert werden. Einen Tokenwert nun irrtumlicherweise mehrfach zu verwenden, würde hiermit unmöglich gemacht werden. Seit der Java-Version 1.5 gibt es erstmals die Möglichkeit mit enum einen Aufzähungstyp in Java zu definieren, was die Deklaration von Token-Typen extrem erleichtert:

public enum TokenType { UNKNOWN, EOS, LPAREN1, RPAREN1, ... }

Dank des neuen Enum−Typen muss man sich als Programmierer, nicht mehr um die eindeutige Wertigkeit einzelner Tokens kümmern. Was unter vielen anderen Programmiersprachen schon lange möglich war, ist nun endlich auch mit Java 1.5 möglich. Sehen Sie hierzu die Tokenklasse von Tinyray−Scanner.

Der Setty−Scanner wird dazu verwendet, Setty−Tokens vom gegebenen String source zu lesen. Folgender Scanner muss zwar nicht viele Token−Typen erkennnen können, dennoch erreicht er eine kaum überschaubare Größe. Warum das so ist, liegt in der Natur eines jeden Scanners, der zwischen vielen Token−Typen unterscheiden muss, besonders wenn manche Tokens den selben Wortanfang haben wie beispielsweise in und inf (Regel des längsten Musters benötigt viel Programmcode). Tipp: Der Lesende sollte sich sofort auf die Methode nextToken() stürtzen, da alles andere in der Klasse Scanner nur Detailkram ist und deshalb auch ein bisschen abschreckend wirken könnte.

Wie Sie sehen, ist die händische Implementierung eines Scanners sehr umfangreich. Fehler kann man bei dieser Vorgehensweise quasi nie ausschließen, deshalb sei zur Entwicklung eines Scanners die Verwendung eines Scannergenerators (JLex oder JFlex) als weitaus sicherere Variante erwähnt. Sie definieren die Tokenmenge in der Regel mit regulären Ausdrücken, damit der Scannergenerator eine Scannerklasse (hier: eine Java-Klasse) automatisch generieren kann, d. h. die Scannerklasse müssen Sie somit nicht selbst schreiben, weil dies der Scannergenerator für Sie erledigt.

Folgende Testklasse zeigt die einfache Handhabung des Setty−Scanners.

Der Setty-Scanner erkennt aber auch Fehler, wenn die gegebene Zeichenkette ungültige Zeichenfolgen enthält. Das Gute hierbei ist, dass der Scanner keine Exception wirft, was den Lesefluss unterbrechen würde, sondern das definierte Ausnahmetoken UNKNOWN zurückgibt. So kann trotz eines Fehlers im Quellprogramm einfach weitergelesen werden. Da dieser Scanner stets einen definierten Folgezustand besitzt, kann dieser Scanner auch als totaler Automat bezeichnet werden. Ohne dem Ausnahmetoken UNKNOWN wäre dieser Scanner nur ein partieller Automat, was nicht praktikabel wäre. Genauer gesagt, handelt es sich beim vorliegenden Scanner um einen totalen, deterministischen, endlichen Automaten.

Im Folgenden kommen ausnahmslos gültige Tokens vor, jedoch mit falscher Grammatik — kein Problem für den Setty−Scanner. Der Parser allerdings würde schon beim ersten Token eine ParseException werfen, weil ein Setty−Programm nicht mit IN, sondern gemäß der Grammatik mit IS beginnt.

Diese Seite ist Bestandteil der Domäne www.stefan−baur.de und heißt Setty−Scanner. Die letzte Änderung erfuhr diese Seite am Freitag, den 21. August 2009 von Stefan K. Baur. Zuletzt wurde sie von Ihnen am Mittwoch, den 8. September 2010 um 3:41 Uhr im Internet besucht. Sie gelangen zur vorliegenden Seite, wenn Sie ausgehend von der Startseite über dem Hauptmenü wie folgt navigieren:

Startseite Informatik Programmiersprachen Interpreter Setty Setty−Scanner

Wenn Sie die vorliegende Seite ausdrucken möchten, nutzen Sie dazu die Printversion.

Werden Sie Autor vorliegender Homepage, informieren Sie sich unter Autoren.

Das aktuelle Design trägt den Namen „Design 2007”. Falls Ihnen jedoch das aktuelle Design nicht zusagen sollte, so stehen Ihnen noch andere, alternative Designs zur Verfügung:

	Design 2010
	Design 2009
	Design 2008
	Design 2006
	Design 2005
	Design 2004

Vorliegender Webauftritt wurde in mühevoller Kleinarbeit von Stefan K. Baur entwickelt. Copyright (c) 2004-2010 Stefan K. Baur