Zur Erinnerung: sowohl “1+2+3″ als auch “1+(” wären Zeichenfolgen, die der Lexer akzeptieren und ohne zu meckern zerkleinern würde. Das ist auch in Ordnung so, da die syntaktische Prüfung ohnehin eher Aufgabe des Parsers ist. Aber was genau gilt es denn dabei zu beachten?

“Syntaxfragen”

• Sind genau so viele öffnende wie schließende Klammern vorhanden und passen diese zusammen?
• Stimmt die Zahl der Parameter, mit der eine Funktion aufgerufen wird?
• Stimmen die Parametertypen, mit denen eine Funktion aufgerufen wird? (“+” arbeitet normalerweise nur auf Zahlen, der Punkt z.B. in PHP auf Strings, etc…)
• Befinden sich Operatoren an den richtigen Positionen? (Die Fakultät einer Zahl wird z.B. durch Anhängen eines Ausrufezeichens gekennzeichnet: “3!”)
• Darf eine Funktion geschachtelt vorkommen? (z.B. wäre “echo(echo(1))” eher sinnlos, wenn “echo” die Ausgabefunktion ist)
• Darf eine Funktion/ein Konstrukt in einer untergeordneten Umgebung vorkommen? (Das wäre z.B. der Fall, wenn man Funktionsdefinitionen innerhalb von Funktionsdefinitionen zulässt.)

Neben der Syntax gibt es noch weitere Punkte, die eine Programmier-/Scriptsprache ausmachen. Eine Auflistung findet man z.B. hier.

Einiges ist schon erledigt

Der im vorhergehenden Teil präsentierte Shunting-Yard-Algorithmus nimmt uns die Überprüfung der Klammern, sowie der Position der Parameter bereits ab. Des weiteren ist es unumgänglich zur Erstellung des Syntaxbaumes die Anzahl der Parameter zu kennen, die eine bestimmte Funktion benötigt. Wir können also unsere Liste auf die Hälfte kürzen.

Einiges noch nicht

Der Syntaxbaum selbst macht die Syntaxprüfung recht simpel. Aber zuerst müssen wir für jede Funktion, jeden Operator und jedes Terminalsymbol festlegen, welche syntaxktischen Eigenschaften es hat. Das wird letztlich mittels einer Klasse SyntaxDefinition realisiert werden, die die entsprechenden Daten kapselt.

Wichtig ist hierbei: wir betrachten all die genannten Datentypen als Funktionen, auch die Terminalsymbole. Jede Funktion hat einen Rückgabetyp und beliebig viele Parametertypvarianten. Eine “Zahl” wäre also eine Funktion mit dem Parametertyp “Zahl” und dem Rückgabetyp “Zahl”.

Eine beispielhafte Aufstellung für die Syntax einer Sprache wäre die folgende:

• Terminalsymbol Integer:
  • Eingabe: Integer
  • Rückgabe: Integer
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• Terminalsymbol String:
  • Eingabe: String
  • Rückgabe: String
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• Terminalsymbol Identifier:
  • Eingabe: Identifier
  • Rückgabe: Identifier
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• Funktion DefConstant:
  • Eingabe: (Identifier, Integer) oder (Identifier, String)
  • Rückgabe: keine
  • Verschachtelung nicht erlaubt
  • Unterordnung erlaubt
• Operator Plus:
  • Eingabe: (Integer, Integer)
  • Rückgabe: Integer
  • Verschachtelung erlaubt
  • Unterordnung erlaubt
• …

Es gibt aber auch Funktionen, deren Rückgabetyp erst zum Ausführungszeitpunkt feststeht. Bestes Beispiel ist hier die Auswertung von Variablen, die ja Werte verschiedenster Typen enthalten können.

Wie würde also nun die Überprüfung der Typkorrektheit und der Verschachtelung ablaufen? Wie bereits erwähnt nutzen wir hierfür den Syntaxbaum und testen jeden einzelnen Knoten unter Berücksichtigung der Kindknoten:

               operator : +
              /            \
        integer : 1     operator : *
                       /            \
                  integer : 2   function : echo
                                     |
                                constant : e

Für unseren Test entspräche das dem folgenden Baum (Notation: “Rückgabe / Verschachtelung erlaubt?”):

               integer / ja
              /            \
        integer / ja    integer / ja
                       /            \
                  integer / ja  void / nein
                                     |
                                runtime / ja

Die Wurzel (das Plus) erwartet zwei Parameter des Typs “integer”. Eine Überprüfung der Kindknoten zeigt, dass diese genau diesen Rückgabetyp besitzen – also alles in Ordnung , auch die Verschachtelung.
Betrachtet man den rechten Ast weiter, sieht man zwei Probleme: die Multiplikation benötigt zwei “integer”-Parameter, erhält aber “integer” und “void” (void ist der Ausdruck für “keine Rückgabe”); und die “echo”-Funktion kann nicht geschachtelt auftreten, befindet sich aber auf Ebene 2.

Einen dieser Fehler sollte der Parser letztlich ausgeben und abbrechen!

Einiges muss warten

Ob ein Ausdruck in einer untergeordneten Umgebung auftritt, kann ein reiner Parser nicht wissen. Man könnte ihm zwar diesbezügliche Informationen zukommen lassen (und sollte das auch, wenn man vorhat, einen Compiler o.Ä. zu schreiben), der einfachste Ort für diese Überprüfung ist jedoch die Auswertung. (Das ist auch scriptsprachentauglich.)

Was die Parametertypen angeht, die erst bei der Ausführung feststehen, kann man entweder mit regulären Ausdrücken arbeiten und mit deren Hilfe die Teilergebnisse untersuchen, bevor man die übergeordnete Funktion aufruft, oder man überlässt das ganz der jeweiligen Funktion selbst. Geschmacksache.

Spezielle Konstrukte

In jeder Sprache gibt es bestimmte Schlüsselwörter, die spezielle Konstrukte beschreiben/einleiten. Gemeint ist soetwas wie:

def a = 2

Der Shunting-Yard-Algorithmus kommt aber nur mit Operatoren oder mit Funktionen der Form “f(p1, p2, …)” klar.

Kein großes Problem?

Gut, das wäre jetzt kein großes Problem für das oben stehende Beispiel: man definiert “def” und “=” als Operatoren, wobei “def” ein Präfix-Operator mit genau einem Parameter ist und eine höhere Priorität als “=” hat. Der Operator “def” legt eine leere Variable mit dem übergebenen Namen an und liefert diesen Namen als Rückgabewert.
“=” wiederum ist ein Infix-Operator mit zwei Parametern, das die (existierende!) Variable des übergebenen Namens mit dem übergebenen Wert füllt.

Der Syntaxbaum für oben genannten Ausdruck wäre dann:

              operator : =
              /          \
     operator : def   integer : 2
             |
     identifier : a

Und schon hätten wir das  gewünschte Verhalten, allerdings auf Kosten der Übersichtlichkeit in der Implementierung, sowie eines sehr großen Freiraums in der Grammatik. Immerhin wäre so etwas dann auch erlaubt:

(((((def a))))) = 2
def b = def a

Ein Verhindern von Verschachtelungen ist hier nicht mehr möglich.

Bessere Lösung

Wir brauchen einen Mechanismus, der aus “def a = 2″ so etwas macht wie “def(a, 2)”, also einen regulären Funktionsaufruf. Es handelt sich hierbei um eine Mustererkennung auf Basis bereits gelesener Token, d.h. die eigentliche Umwandlung findet nach dem erstmaligen Einlesen der Eingabesequenz durch den Lexer statt:

keyword : def
identifier : a
operator : =
integer : 2

wird zu

function : def
open : (
identifier : a
comma : ,
integer : 2
close : )

In meinen Augen bietet sich hierfür wieder  der in Teil 1 unter Alternative 4 vorgestellte Algorithmus an, der z.B. mit einem Automaten arbeiten könnte, der die folgende Akzeptanzfunktion besitzt (Vorsicht: Pseudocode!):

private int tokenNumber = -1;
public bool accept(Token t)
{
    tokenNumber++;
    return
        (tokenNumber == 0 && "t ist vom Typ 'keyword' und hat den Wert 'def'") ||
        (tokenNumber == 1 && "t ist vom Typ 'identifier'") ||
        (tokenNumber == 2 && "t ist vom Typ 'operator' und hat den Wert '='") ||
        tokenNumber > 2;
}

Gleichzeitig müssten irgendwo die relevanten Token gesichert werden, damit die Umwandlung in eine Funktion später auch reibungslos vonstatten gehen kann.

Ich würde sagen, damit haben wir eine vernünftige Lösung gefunden.

Fazit

Wir können nun unseren Syntaxbaum auf syntaktische Merkmale hin untersuchen und spezielle Ausdrücke und Konstrukte berücksichtigen. Langsam sollten wir uns also an die Ausführung eines Ausdrucks machen.

Ein in diesem Artikel häufig verwendetes Wort war “Umgebung”. Es handelt sich dabei um den Speicher für Variablen, Funktionen, etc… Ohne diesen ist die Entwicklung einer Scriptsprache relativ witzlos, weswegen wir an genau dieser Stelle weitermachen werden.

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax

zahl        :    1
operator    :    +
zahl        :    3
operator    :    *
open        :    (
zahl        :    4
operator    :    -
zahl        :    2
close       :    )

Damit haben wir eine maschinenlesbare Repräsentation des gewünschten Ausdrucks – allerdings keine Garantie dafür, dass dieser syntaktisch korrekt ist. Ebensowenig kann eine Maschine, die diese Liste nun vorgelegt bekommt, “einfach mal so” den Wert des Ausdrucks berechnen, da ihr Informationen zur Auswertungsreihenfolge fehlen. (Wenn 1+3 zuerst berechnet wird, lautet das Ergebnis 8, wenn 3*(4-2) zuerst berechnet wird, lautet es 7.)

Wir brauchen also eine Darstellung unseres Ausdrucks, die bezüglich der Reihenfolge der Auswertung eindeutig ist und eine Maschine, die diese erstellt  – und wie könnte es anders sein: auch dieses Problem wurde bereits einmal gelöst.

Wandeln wir also auf den Spuren von Edsger W. Dijkstra.

Reverse Polish Notation

Der polnische Mathematiker Jan Łukasiewicz entwickelte etwa 1920 die sog. Polnische Notation für arithmetische Ausdrücke, die sich dadurch auszeichnete, dass jedem Operator (“+”, “-”, …) direkt seine Operanden (Zahlen oder weitere arithmetische Ausdrücke) folgten. Durch diese Präfixnotation ergibt sich die Möglichkeit, auf Klammern, Kommas, etc… verzichten zu können, wenn man weiß, wie viele Operanden ein Operator benötigt:

1+2+3         ==>        + 1 + 2 3           (auch: + + 1 2 3)
1+3*(4-2)     ==>        + 1 * 3 - 4 2
(3+4)*(4*3-1) ==>        * + 3 4 - * 4 3 1

Anhand des letzten Beispiels will ich die Auswertung so eines Ausdrucks beschreiben. Das Prinzip ist: “Werte den Ausdruck, der nur Zahlen als Operanden hat, als nächstes aus!”

   * + 3 4 - * 4 3 1        |   Das + bezieht sich auf 3 und 4!
=  * 7     - * 4 3 1        |   Das * bezieht sich auf 4 und 3!
=  * 7     - 12    1        |   Das - bezieht sich auf 12 und 1!
=  * 7     11               |   Das * bezieht sich auf 7 und 11!
=  77

Wie bereits erwähnt, funktioniert so eine Auswertung nur, wenn man weiß, wie viele Operanden/Parameter ein Operator/eine Funktion benötigt. Deswegen haben wir uns bei der Entwicklung des Lexers auch die Mühe gemacht, diese Information immer irgendwie bei der Hand zu haben.

Was Dijkstra nun gemacht hat, war, aus der Präfix- eine Postfixnotation zu machen, die sog. Reverse Polish Notation (RPN). Hier stehen nun alle Operanden vor dem Operator zu dem sie gehören:

1+2+3         ==>        1 2 3 + +          (auch: 1 2 + 3 +)
1+3*(4-2)     ==>        1 3 4 2 - * +
(3+4)*(4*3-1) ==>        3 4 + 4 3 * 1 - *

Sowohl Polish Notation als auch Reverse Polish Notation beschreiben (unter der Voraussetzung, dass man die Anzahl der Parameter/Operanden kennt) eine eindeutige Auswertungsreihenfolge. Bei der letztlichen Auswertung ist die RPN aber ihrem Vorfahren in Bezug auf Speicherverbrauch und Verständlichkeit dann doch voraus. Die Regel: “Wenn ein Operator auftaucht, werte ihn aus!”

Wir benötigen hierbei einen Stack, der die Zwischenergebnisse speichert und der diese bei Auftreten eines Operators zur Berechnung zur Verfügung stellt.

----------------------------------------------------------------------------------
Eingabe            | Stack    |  Kommentar
----------------------------------------------------------------------------------
3 4 + 4 3 * 1 - *  |          |  Beginn des Algorithmus
4 + 4 3 * 1 - *    | 3        |  Zahl (3): auf den Stack!
+ 4 3 * 1 - *      | 3 4      |  Zahl (4): auf den Stack!
4 3 * 1 - *        | 7        |  Operator (+): hole 3 und 4, berechne, speichere
3 * 1 - *          | 7 4      |  Zahl (4): auf den Stack!
* 1 - *            | 7 4 3    |  Zahl (3): auf den Stack!
1 - *              | 7 12     |  Operator (*): hole 4 und 3, berechne, speichere
- *                | 7 12 1   |  Zahl (1): auf den Stack!
*                  | 7 11     |  Operator (-): hole 12 und 1, berechne, speichere
                   | 77       |  Operator (*): hole 7 und 11, berechne, speichere
                   | 77       |  Eingabe leer, Ergebnis auf Stack.

Dies umzusetzen ist kein großes Problem und spricht in jedem Fall für die Reverse Polish Notation als Darstellung eines auszuwertenden Ausdrucks. Und dann wäre da noch die kleine, aber feine Tatsache, dass es einen Algorithmus gibt, der die Umwandlung “normaler” (Infix-)Ausdrücke (à la “1+2*f(3)”) in diese Notation vornimmt.

Der Shunting-Yard-Algorithmus

Der Shunting-Yard-Algorithmus (zu deutsch: Rangierbahnhofalgorithmus) ist eine ebenfalls von Dijkstra entwickelte Methode zur Umwandlung von Infix-Ausdrücken in Postfix-Notation. Sein Name kommt daher, dass seine Funktionsweise den Abläufen in einem Rangierbahnhof entspricht: alle terminalen Symbole (z.B. Zahlen, Variablen, …) sind Waren und Güter, die von Zügen (den nichtterminalen Symbolen wie Operatoren und Funktionen) mitgenommen werden müssen.

Die folgende Animation zeigt (vereinfacht) das Prinzip des Algorithmus. Er basiert darauf, dass in der Zugwarteschlange immer der Zug mit der höchsten Priorität (in der Realität z.B. die Geschwindigkeit) ganz vorne steht. Will sich ein langsamerer Zug einreihen, müssen also zuerst alle schnelleren Züge losgefahren sein. (Jeder Zug kann beliebig viele Waren transportieren und nimmt beim Abfahren alle verfügbaren mit! Es kann also auch passieren, dass ein Zug leer losfährt.)

Übertragen auf die Reverse Polish Notation: Die Operationen mit der niedrigsten Priorität werden zuletzt ausgeführt, entsprechen also den langsamsten Zügen. Mit ein wenig Überlegung sieht man, dass der Algorithmus also genau das Ergebnis liefern wird, was wir haben wollen!

Die Waren-Schlange kann übrigens in der letztlichen Implementierung entfallen, wenn man alle Waren einfach direkt zum Ausgang schiebt und immer nur den Zug voranstellt, der sie mitnehmen soll.

Hinzu kommt noch die Behandlung von Klammern und Trennsymbolen (z.B Kommas). Ich möchte den Algorithmus hier nicht im Detail aufschreiben, da der zugehörige Wikipedia-Artikel (englisch) eine genaue Beschreibung enthält.

Wichtig ist:

• Der Algorithmus kann Operatoren, Terminalsymbole, Klammern, Trennzeichen und Funktionen verarbeiten, d.h. wenn wir spezielle Konstrukte haben (z.B. “def x=a*(b-1)”) müssen wir diese erst in Funktionsform bringen. (z.B. “definition(x, a*(b-1))”)
• Der Algorithmus hat eine Laufzeit in O(n), d.h. er ist vergleichsweise effizient.

Reverse Polish Notation vs. Syntaxbaum

Eine weitere Möglichkeit, die Ausführungsreihenfolge eindeutig festzulegen, ist das Erstellen eines Syntaxbaumes. Für den Ausdruck “1+2*sqrt(e)” hat dieser z.B. die folgende Form:

               operator : +
              /            \
        integer : 1     operator : *
                       /            \
                  integer : 2   function : sqrt
                                     |
                                constant : e

Die Auswertung erfolgt von unten nach oben, d.h. bei der letztlichen Berechnung würden folgende Schritte ausgeführt:

e                 => 2.71
sqrt(2.71)        => 1.65
2                 => 2
2 * 1.65          => 3.3
1                 => 1
1 + 3.3           => 4.3

Das besondere ist, das jeder Syntaxbaum sehr einfach in Reverse Polish Notation umgewandelt werden kann und jede RPN ebenso einfach in einen Syntaxbaum.

Für erstere Umwandlung durchläuft man den Baum als Post-Order-Traversierung, d.h. man schreibt ausgehend von der Wurzel zuerst die Post-Order-Notation der Kindknoten auf und hängt anschließend den Wert der Wurzel daran an.

Für die entgegensetzte Transformation tut man so, als würde man die RPN-Notation auswerten (siehe oben!), aber anstatt auf dem Stack Zwischenergebnisse zu speichern, sichert man dort die Teilbäume:

-----------------------------------------------------------------------------------
Eingabe            | Stack           |  Kommentar
-----------------------------------------------------------------------------------
3 4 + 4 3 * 1 - *  |                     |  Beginn des Algorithmus
4 + 4 3 * 1 - *    | 3                   |  Zahl (3): Blatt auf den Stack!
+ 4 3 * 1 - *      | 3 4                 |  Zahl (4): Blatt auf den Stack!
4 3 * 1 - *        | +(3,4)              |  Operator (+): hole Blätter, bilde Baum
3 * 1 - *          | +(3,4) 4            |  Zahl (4): Blatt auf den Stack!
* 1 - *            | +(3,4) 4 3          |  Zahl (3): Blatt auf den Stack!
1 - *              | +(3,4) *(4,3)       |  Operator (*): hole Blätter, bilde Baum
- *                | +(3,4) *(4,3) 1     |  Zahl (1): Blatt auf den Stack!
*                  | +(3,4) -(*(4,3), 1) |  Operator (-): hole Blatt/Teilbaum, bilde Baum
[...]

Ergebnis: *(+(3,4), -(*(4,3), 1))

Ich hoffe die Baumnotation “Wurzel(Teilbaum1, Teilbaum2, …)” ist verständlich.

Es gibt hierzu noch eine weitere wichtige Anmerkung:
Jeder Algorithmus, der die Reverse Polish Notation eines Ausdrucks erstellen kann, kann so modifiziert werden, dass er einen Syntaxbaum erstellt und jeder Algorithmus, der einen Syntaxbaum erstellt, kann auch die RPN eines Ausdrucks erstellen!

Beide Darstellungen sind also gleichwertig in der Funktionalität, der Syntaxbaum benötigt jedoch mehr Speicherplatz, außerdem ist eine Auswertung des Baumes auf rekursivem Weg ebenfalls nicht gerade resourcenschonend.

Fazit

Auch wenn die Reverse Polish Notation eines Ausdrucks Verarbeitungsvorteile mit sich bringt, erschwert sie die Untersuchung der Eingabe auf syntaktische Korrektheit (vor allem Typkorrektheit!). Unser Parser muss also intern einen Syntaxbaum erstellen, diesen überprüfen und anschließend die RPN des Ausdrucks ausgeben. Damit dürften wir auf der sicheren Seite sein.

Nur: Was ist eigentlich Syntax?

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax
   

Vor allem die letzte Frage kann einem zu schaffen machen. Warum etwas möglicherweise nicht gut funktionierendes entwickeln, wenn es doch überall schon tausendfach durchdachte Lösungen gibt? Immerhin lautet doch eine der obersten Regeln in der Softwareentwicklung:

Don’t reinvent the wheel!

Nun, ich bin Informatikstudent. Ich will wissen, wie die Dinge “unter der Haube” aussehen, ich will lernen. Und wenn alle nur noch auf vorgefertige Bibliotheken zurückgreifen, weiß doch bald keiner mehr, was dem Zauber eigentlich zugrunde liegt… Dementsprechend:

Don’t reinvent the wheel, unless you plan on learning more about wheels!

Diese Anleitung soll jedem helfen, der interessiert daran ist, was im Inneren eines Interpreters oder Compilers eigentlich (ungefähr so) abläuft. Ich selbst habe gerade erst das zweite Semester hinter mir, d.h. allzu theoretisch wird es hier nicht und jeder mit ein wenig logischem Denken und genug Engagement sollte es hinbekommen, meinen Ausführungen zu folgen.

Lasset uns beginnen.

Der Lexer

Ein lexikalischer Scanner (kurz: Lexer) ist eine “Maschine”, die eine Zeichenfolge als Eingabe erhält und diese in kleinere Teile spaltet, denen eine bestimmte Bedeutung/ein bestimmter Typ zugrunde liegt.

Ein Taschenrechner, beispielsweise, kennt Zahlen, Operatoren und Klammern. Gibt man dem Lexer dieses Taschenrechners nun die Folge “1+2*(4-3)” zur Verarbeitung, wird daraus die folgende (oder eine ähnliche) Liste:

zahl        :    1
operator    :    +
zahl        :    2
operator    :    *
open        :    (
zahl        :    4
operator    :    -
zahl        :    3
close       :    )

Die einzelnen Zeilen nennt man Tokens. Sie bestehen aus einem Typ (“zahl”, “operator”, …) und einem Wert (“1″, “+”, …) und kapseln somit alle Informationen, die man benötigt, um damit weiterzuarbeiten.

Wichtig ist folgendes: der Lexer überprüft nicht den “Sinn” der Eingabe, d.h. auch ein nicht wohlgeformter Ausdruck wie “1+)(*2″ würde von ihm brav und folgsam in eine Liste von Tokens umgewandelt werden. Die semantische Überprüfung erfolgt an anderer Stelle: dem Parser.

Prinzip

Wie schreibe ich einen Lexer? Das ist keine allzu schwere Sache, die Frage ist nur, wie effizient er letztlich ist. Ich werde hier verschiedene Ansätze darstellen, die jeweils Vor- und Nachteile haben.

Ansatz 1: Reguläre Ausdrücke auf den Anfang der Eingabesequenz anwenden
(~ nicht naiv, aber auch nicht so der Hammer)

• Der Lexer verwaltet eine Reihe von Datentypen, die durch reguläre Ausdrücke (Testen kann man z.B. hier) eindeutig definiert sind. Also z.B.:

  zahl   =>    [0-9]+
  id     =>    [a-zA-Z]+
  open   =>    \(
  close  =>    \)
  comma  =>    ,
  op     =>    [+\-]
  ...

• Auf Basis dieser Typen erfolgt nun die Umwandlung einer Eingabezeichenfolge in Tokens:
  • Erstelle eine leere Ausgabeliste.
  • Während die Zeichenfolge nicht leer ist:
    1. Vergleiche den Anfang der Zeichenfolge mit den regulären Ausdrücken aller verfügbaren Datentypen, bis du einen Treffer landest.
    2. Kein Treffer: Die Zeichenfolge enthält einen unbekannten Datentyp!
    3. Ansonsten:
       • Schneide den gefundenen Ausdruck von der Eingabezeichenfolge ab.
       • Erstelle ein Token des gefundenen Typs und hänge es an die Ausgabeliste an.
    4. Gib die Ausgabeliste aus.
• Ein Token enthält (wie bereits erwähnt) den Typ und Wert eines Ausdrucks. Des weiteren könnte es sich anbieten, auch jeweils Verweise zum vorhergehenden und nachfolgenden Token bereitzustellen, die ja Einfluss auf den realen Typ eines Tokens haben können.
  (Ein Plus benötigt z.B. normalerweise zwei Parameter, wenn aber vor dem Plus ein anderer Operator und danach eine Zahl steht, ist diese Zahl der einzige Parameter und das Plus ist ein Vorzeichen. Die Methode, die solche Sachen überprüft, sollte in der Implementierung der Datentypen auftauchen!)

Der Vorteil dieser Methode ist die Erweiterbarkeit. Wenn man einen neuen Typen hinzufügen will, erstellt man einfach den dazugehörigen Ausdruck. Den Rest übernimmt der Lexer.

Ein gewaltiger Nachteil ist die Zuverlässigkeit: oft gibt es Mehrdeutigkeiten bei regulären Ausdrücken und der Lexer weiß nicht, welcher gerade der richtige ist. Außerdem lässt die Geschwindigkeit zu wünschen übrig: Im schlimmsten Fall (die gesamte Eingabe besteht aus n Tokens des gleichen Typs und dieser Typ ist der letzte, der überpürft wird) beträgt  bei einer Gesamtzahl von m Datentypen die Laufzeit: O(n*m*O(regulärer Ausdruck)) also vermutlich irgendetwas im Bereich O(m*n²)

Ansatz 2: Spezialisierung auf bekannte Eingabetypen
(~ naiver Ansatz)

Wenn man den Lexer nicht für beliebige Datentypen und -formate ausrichtet, sondern von vornherein weiß, wie viele es davon gibt und wie sie aussehen, kann man die Realisierung einfacher/verständlicher machen:

1. Initialisiere einen Zähler i mit 0 und eine leere Liste für die Ausgabe.
2. Während i kleiner ist als die Länge der Eingabe:
   • Überprüfe das i-te Zeichen.
   • Wenn es eine Zahl ist, erhöhe i so lange um eins, bis das i-te Zeichen keine Zahl mehr ist und erstelle aus den dabei “überstrichenen” Zeichen ein Token des Typs “integer”. (Erstellt Token für Zahlen.)
   • Wenn es ein Buchstabe ist, erhöhe i so lange um eins, bis das i-te Zeichen weder Zahl noch Buchstabe ist und erstelle aus den dabei überstrichenen Zeichen ein Token des Typs “identifier”. (Erstellt Token für Variablen)
   • Wenn es ein Anführungszeichen ist, erhöhe i so lange um eins, bis das i-te Zeichen ebenfalls ein Anführungszeichen und das (i-1)-te Zeichen kein Backslash ist [...] (Erstellt Token für Strings)
   • usw…
   • Hänge das erstellte Token an die Ausgabeliste an.
3. Gib die Ausgabeliste aus.

Der Vorteil ist ganz klar die Geschwindigkeit: Jedes Zeichen der Eingabesequenz wird höchstens zweimal überprüft, d.h. die Laufzeit liegt in O(n).

Nachteile sind hier die umständliche Erweiterbarkeit, sowie der meist aufgeblähte Code.

Ansatz 3: Endlicher Automat
(~ professionell und kompliziert (?))

Ansatz 2 war schon nichts anderes als die prinzipielle Funktionsweise eines endlichen Automaten: Ausgehend von einem aktuellen Zustand (z.B. “Kein Zeichen überprüft”, “Stringbeginn entdeckt”) und einer Eingabe (z.B. das nächste Zeichen) geht der Automat in einen neuen Zustand (z.B. “Unerlaubtes Zeichen”, “Stringinhalt”) über. Wenn irgendwann ein Ausgabezustand erreicht wird, erhält man das gerade gelesene Token.

Wenn wir beispielsweise nur die Schlüsselwörter “echo” und “echtheit” hätten, ergäbe sich folgender Automat. (Startsymbol: S, Endsymbol E):

                                         "echo" -----> E("echo")
    e          c           h          o /
S -----> "e" -----> "ec" -----> "ech"
                                      t \         h              e
                                         "echt" -----> "echth" -----> ... -----> E("echtheit")

Wenn ein Zustandsübergang nicht möglich ist, hat man es mit einer unerlaubten Sequenz zu tun. Ein detaillierteres Beispiel zur Modellierung eines endlichen Automaten findet man hier.

Das besondere an endlichen Automaten ist, dass jeder reguläre Ausdruck in so einen Automaten verwandelt werden kann. Eine detaillierte Beschreibung für Interessierte gibt es hier (Uni Bremen).

Vor- und Nachteile entsprechen Ansatz 2, die Laufzeit beträgt ebenfalls O(n). Endliche Automaten werden von fast allen Lexer-/Parser-Generatoren (auf Basis einer Grammatik) erstellt, sind also der meistverbreitete Ansatz zum Erstellen eines Lexers.

Ansatz 4: “Akzeptanztest” auf Basis vieler kleiner Typ-Automaten
( ~ Symbiose von Ansatz 1 und 3)

Ich stand also nun vor dem Problem, zwischen Effizienz und Erweiterbarkeit abzuwägen – genauer gesagt: mich für eines von beiden entscheiden zu müssen – und das passte mir nicht wirklich. Also, zur Ablenkung mal weg vom Schreibblock und Computer, zum Lidl einkaufen und Flaschen zurückbringen. Was man halt so tut.

Und da war er: ein Pfandflaschen-Rückgabe-Automat, der nichts anderes tat, als tagein, tagaus Flaschen anzunehmen und zu überprüfen. Passte die Flasche, gab es einen Zettel, der bares Geld wert war, passte sie nicht, eine Fehlermeldung.

Warum erzähle ich das? Nun, dieser Automat war die Lösung für mein Problem!
Man braucht viele kleine, auf einen bestimmten Typ (von Token, von Flaschen, …) spezialisierte Automaten, die anhand der bereits zuvor eingegebenen Daten (gelesene Zeichen, akzeptierte Flaschen, …) sagen, ob sie eine Eingabe (das nächste Zeichen, die nächste Flasche, …) akzeptieren. Oder eben nicht.

Das Beispiel aus Ansatz 3  würde hierbei so realisiert: Sowohl der “echo”-Automat, als auch der “echtheit”-Automat würden die Eingaben “e”, “c” und “h” (in dieser Reihenfolge) akzeptieren, aber wenn nun ein “o” kommt, wird sich der “echtheit”-Automat aufregen. Für die weitere Überprüfung kann er also ignoriert werden. Und erst wenn auch der “echo”-Automat nicht mehr weitermachen will (also nach besagtem “o”), hat man sein Token gefunden und kann es über die Ausgabefunktion des Automaten auslesen.

Allgemein: Man habe eine Menge A von Typ-Automaten und eine Eingabesequenz <s₀, s₁, s₂, s₃, …, s_n>

1. Versetze alle Automaten in A in ihren Ausgangszustand. (Reset)
2. Finde alle Automaten in A, die s₀ akzeptieren und bilde aus ihnen die Menge A₀
3. Initialisiere i mit 0. Während 0 <= i < n:
   • Wenn |A_i| = 0: brich Schleife ab.
   • Ansonsten: Finde alle Automaten in A_i, die s_i+1 akzeptieren und bilde aus ihnen die Menge A_i+1
   • Erhöhe i um 1.
4. Wenn i=0: Ungültiger Ausdruck.
5. Ansonsten: Finde einen  passenden Typ aus A_i-1 bis A₀, der sich in einem Ausgabezustand befindet (der Index der entsprechenden Automatenmenge sei j), und erstelle ein Token mit dem Wert <s₀, s₁,…, s_j> und dem gefundenen Typen.
6. Fahre mit der restlichen Eingabesequenz fort.

Betrachten wir die Laufzeit: Schritt 1 liegt in O(|A|), Schritt 2 ebenfalls. Schritt 3 benötigt im schlimmsten Fall (die Zeichenfolge wird von allen Automaten komplett akzeptiert) eine Laufzeit von O(n*|A|). Schritt 5 kann ebenfalls eine Laufzeit in O(n*|A|) erreichen, wenn kein einziger Automat in einem Ausgabezustand ist, die restlichen Schritte haben einen konstanten Zeitbedarf O(1).

Diese Methode ermittelt also den nächsten Token mit einer Laufzeit von O((2n+2)*|A|+1), also O(n*|A|). Gleichzeitig ist Erweiterbarkeit gewährleistet, da die Typ-Automaten sehr leicht zu implementieren sind und der Lexer sie nicht von vornherein kennen muss.

Zuverlässigkeit ist nur in Schritt 5 fraglich: Was ist der “passende Typ” zu einem Token? Hier könnte man ein hierarchisches System einführen, das z.B. festlegt: “Wenn die Wahl zwischen dem Typ Funktion und dem Typ Bezeichner getroffen werden muss, nimm die Funktion!”

Die Funktion eines Integer-Automats, die überprüft, ob ein Zeichen akzeptiert wird, könnte z.B. so aussehen:

public bool Accept(char c)
{
    switch (char)
    {
        case '0': case '1': case '2': case '3': case '4':
        case '5': case '6': case '7': case '8': case '9':
            return true;
        default:
            return false;
    }
}

Damit kann man leben, oder? Schwieriger wird es erst bei solchen Sachen wie Strings, wo z.B. beachtet werden muss, dass ein gültiges Zeichen, das nach dem Schließen des Strings kommt, natürlich nicht mehr akzeptiert werden darf. (Man müsste also im Automaten selbst weitere Zustandsdaten, z.B. einen boolschen Wert stringClosed oder so, speichern.)

Fazit

Um eine größtmögliche Erweiterbarkeit zu gewährleisten und weil ich stolz auf die Idee bin und überprüfen will, wie sie sich umsetzen lässt, werden wir Ansatz 4 implementieren. Ich frage mich allerdings, was “Pfandflaschenalgorithmus” auf Englisch heißt…

Update (30.08.2009):
Eine bessere Analogie für den Algorithmus wäre statt dem Pfandflaschenautomaten wohl ein Rennen oder ein Wettbewerb: derjenige, der am weitesten kommt (“die meisten Eingaben akzeptiert), ist der Sieger – außer er bricht dann zusammen, fängt an zu heulen, etc… (“außer er befindet sich nicht in einem Ausgabezustand”) In dem Fall gewinnt der zweite Platz (der aber identisch mit dem ersten sein kann), außer auch dieser kommt mit dem Druck nicht klar. Und so weiter.

Implementierung

Bei der Implementierung des Lexers sollten gleich alle verfügbaren Datentypen (Operator, Trennzeichen, Terminalausdruck, …) in eigenen Klassen gekapselt werden. Das macht die spätere Verwendung einfacher.

Zwei Sachen sollten hier näher erläutert werden. Zuerst die Methode signification der Klasse SyntaxType: sie ermittelt anhand eines konkreten Tokens den “wirklichen Typ” dieses Tokens. Man könnte z.B. einen Grundtyp Identifier definieren (als Unterklasse von Terminal), der alle Buchstabenfolgen (keine Zahlen, keine Sonderzeichen) repräsentiert. Die signification-Methode könnte dann ermitteln ob der Identifier eine Variable, ein Listenname, eine Konstante, etc… ist und dies zurückliefern. Oder eben oben genanntes Beispiel mit dem Pluszeichen, das abhängig vom Kontext ein Operator oder ein Vorzeichen sein kann.

Zweitens das Interface IStateMachine: Es kapselt die für Ansatz 4 (s.o.) benötigten Operationen. (Die Methode IsOutputState fehlt, sollte aber nicht vergessen werden!)

Update (12.08.2009):
Datentypen, die spezielle, angepasste Methoden signification benötigen, müssen als Unterklassen der jeweiligen Typen (hauptsächlich Terminal vermutlich) definiert werden und die Methoden überschreiben. Nur, falls das noch nicht klar war.

Gesamtfazit

Nun kommen wir leicht an die einzelnen Bestandteile eines Ausdrucks, aber uns fehlen noch die Mittel, damit richtig umzugehen. Der nächste Schritt ist es also, Regeln für unsere verschiedenen Ausdrücke zu erstellen (Welche Art von Parametern benötigt eine Funktion/ein Operator/ein Pattern? Darf eine Funktion verschachtelt ausgeführt werden? Etc…) und anhand dieser Regeln einen gegebenen Ausdruck zu überprüfen und in eine einfach weiterzuverarbeitende Form zu bringen.

Hier kommt der sog. Syntaxbaum ins Spiel. Und der Parser, der ihn erstellt.

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax
   

Vorspiel

Neben LastSharp und LeSharp, den beiden Tools, die für eine breite Masse gedacht und deshalb auch zumindest ein bisschen nützlich sind, arbeite ich noch an zwei eher theoretischen Projekten: UVD (das im Moment ruht) und Lapicon (Loose API Connection Language).

Letzteres ist eine Scriptsprache zum Senden und Verarbeiten von REST-Requests, also zum Verwenden verschiedenster APIs, z.b. dem von Last.FM. Kein großer Leckerbissen für den Otto-Normal-Benutzer also und auch für Entwickler, die sich mit dem Thema beschäftigen, ist die Sprache nicht der Inbegriff von Eleganz. Deshalb mein Entschluss: Lapicon muss von Grund auf neu entwickelt werden. Das bedeutet: neue Funktionen, mehr Komfort, bessere Performance, usw… Alles in allem keine triviale Aufgabe.

Und dann kam mir die Idee, meinen Versuch zu protokollieren und somit allen, die daran interessiert sind, eine eigene Programmier- oder Scriptsprache zu entwickeln, ein Stückchen weiterzuhelfen. Eine kleine Reise, ein kleines Abenteuer also.

Ein Hinweis

Das Konzept, das hier entwickelt wird, eignet sich für Sprachen, die – so will ich es jetzt aus Ermangelung eines Fachbegriffs mal nennen – “blockbasiert” sind, also so etwa wie Pascal oder VHDL. D.h. man hat (z.B. bei Funktionen) immer einen Start- und einen Endblock, wobei der Endblock überflüssig werden kann, wenn man Sachen wie Zeileneinrückung einbezieht. (Ein Konzept, dass ich, während ich mich in Ruby eingearbeitet habe, bei HAML und SASS kennen- und schätzen gelernt habe.)

Des weiteren werden wir zur Erkennung verschiedener Anweisungen mit Regular Expressions arbeiten, weshalb man sich dort auskennen sollte. Ein Tutorial gibt es z.B. hier (englisch).

Reisevorbereitung

Bevor wir uns überhaupt mit der Sprache selbst beschäftigen, sollten wir folgendes tun:

1. Wir müssen uns überlegen, welche Komponenten wir entwickeln müssen, um Ausdrücke zu erkennen und zu verarbeiten.
   Die Schlagworte hier sind Lexer und Parser. (Ich hatte anfangs ein anderes Konzept vorgesehen, das aber einen Haufen Schwächen hatte, weshalb ich jetzt doch wieder auf das klassische Prinzip zurückkomme. Ich werde mich bemühen, das so gut wie möglich darzustellen…)

   Der Lexer nimmt einen Ausdruck und zerlegt ihn in sog. Token, d.h. in kleine Teile, die einen Typ und einen Wert besitzen. Man nehme beispielsweise den Ausdruck “1+2*sqrt(e)”. Ein Lexer (auch Tokenizer genannt) könnte daraus eine Liste der folgenden Gestalt fabrizieren:

   integer  : 1
   operator : +
   integer  : 2
   operator : *
   id       : sqrt
   open     : (
   id       : e
   close    : )

   Der Parser nimmt nun diese Liste und erstellt daraus einen Syntaxbaum, d.h. eine Repräsentation des Ausdrucks als Baumstruktur. Hier wird vor allem darauf geachtet, dass verschiedene Operatoren verschiedene Prioritäten haben können, dass es Verschachtelungen durch Klammern gibt, etc… Ein Syntaxbaum für unser Beispiel könnte nach dem Parsen z.B. so aussehen:

                  operator : +
                 /            \
           integer : 1     operator : *
                          /            \
                     integer : 2   function : sqrt
                                        |
                                   constant : e

2. Wir müssen festlegen, was die Sprache können soll.
   Welche Datenstrukturen sollen zugänglich sein? Kann man Funktionen definieren? Gibt es arithmetische Operationen? Schleifen? Man sollte sich eine Liste machen. Für unsere Beispielsprache könnte das so aussehen:
   • Es gibt zwei Datentypen: Zahlen und Strings.
   • Es gibt Variablen, die aber nur Zahlen enthalten können.
   • Es gibt eine Ausgabefunktion, die Strings und Zahlen ausgibt.
   • Es gibt eine Ausgabefunktion, die Zeilenumbrüche erzeugt.
   • Es gibt eine Eingabefunktion, die Zahlen einliest und in einer Variablen speichert.
   • Es gibt die arithmetischen Operationen Addition (+), Subtraktion (-), Multiplikation (*), Division (/), die auf ganzen Zahlen arbeiten.
   • Es gibt Klammern, mit denen man die Ausführungsreihenfolge beeinflussen kann.
   • Es gibt eine Schleife, die einen Befehl genau n-mal (n ist gegeben) ausführt.
   • Es gibt drei Funktionen, die jeweils überprüfen, ob eine Zahl größer, kleiner oder gleich 0 ist und bei zutreffendem Ergebnis, einen Fehler ausgeben.

   Was wir also entwickeln werden, ist ein Taschenrechner.

3. Wir müssen uns Gedanken dazu machen, wie der Interpreter aufgebaut ist und arbeitet.
   Wie genau wird unser Programmcode verarbeitet? Wie arbeitet der Interpreter intern?An dieser Stelle wird klar, warum ich mich dafür entschieden habe, eine “blockbasierte” (also mit expliziten Blockanfängen und -enden) Sprache zu entwickeln: es ermöglicht die Ausführung eines Programms Zeile für Zeile. (Zwar wäre es kein unerträglicher Aufwand, auch so etwas wie Klammerstrukturen, ähnlich zu C#, unterstützen zu lassen, aber es geht auch so – und macht außerdem den Quelltext strukturierter, wie man z.B. an Ruby sieht.)

   Das andere Konzept, das den Interpreter zu einem nützlichen Interpreter macht, habe ich bei der Mikroprogrammierung näher kennengelernt. Man hat einen Instruktionszeiger (Instruction Pointer, IP), der auf die aktuelle Instruktion zeigt und einen Stack, der den Wert des Zeigers zwischenspeichern kann. Jede Anweisung sagt dem Interpreter nach ihrer Ausführung, was er nun weiter machen soll. Zyklus:

   1. Hole die Anweisung (Statement), auf die der IP gerade zeigt. Ist keine Anweisung vorhanden, brich ab.
   2. Übergib die Anweisung an den Verarbeiter (Processor) und speichere das Ergebnis.
   3. Lies aus dem Ergebnis die folgenden Teile aus: Zeiger-Offset, Zeiger-Aktion und Stack-Aktion.
   4. Wenn die Stack-Aktion “PUSH” ist, lege den IP auf den Stack.
   5. Wenn die Zeiger-Aktion “NULL” ist, setze den IP auf 0, ist sie “STACK”, setze den IP auf die Position, die zuoberst auf dem Stack liegt. Bei “CONTINUE” erhöhe den IP um 1.
   6. Wenn die Stack-Aktion “POP” ist, nimm das oberste Element vom Stack.
   7. Addiere den Zeiger-Offset auf den Instruktionszeiger.
   8. Gehe zu 1.

   Beispiel: Schleife, die mindestens einmal ausgeführt wird
   (Notation: Zeiger-Offset, Zeiger-Aktion, Stack-Aktion)

   Schleifenbeginn: 0 / CONTINUE / PUSH
   Schleifenrumpf: beliebig
   Schleifenbedingung erfüllt: 1 / STACK / NONE
   Schleifenbedingung nicht erfüllt: 0 / CONTINUE / POP

   Beispiel 2: Funktionsaufruf

   Aufruf: <Adresse+1> / NULL / PUSH
   Rumpf: beliebig
   Rücksprung: 1 / STACK / POP

   Der Processor ist das, wo die eigentliche Ausführung  eines Befehls stattfindet. Er tut folgendes:

   1. Erstelle mithilfe von Lexer und Parser (siehe oben) den Syntaxbaum des Befehls.
   2. Wenn der Baum Kindknoten hat, werte zuerst die jeweiligen Teilbäume aus. (Top-Down-Methode)
   3. Schaue, ob für den Typ des Wurzelknotens eine Verarbeitungsroutine (Evaluator) existiert. Wenn ja, rufe sie mit den in 2. ermittelten Daten auf und gib ihr Ergebnis zurück, wenn nicht, gib eine Fehlermeldung aus und brich die Gesamtausführung ab.
4. Und wie werden die programminternen Daten gespeichert?
   Wir benötigen eine Umgebung, in der ein Programm läuft. Diese Umgebung hat vor allem die Aufgabe, Variablen, Objekte, Funktionen, Listen, Arrays, etc… zu verwalten, also eine große Menge an Daten zu speichern und zugreifbar zu machen. Wenn man von vornherein weiß, was auf einen zukommt (wenn man also einen Interpreter für eine ganz bestimmte und ganz genau definierte Sprache schreibt), kann man es sich einfach machen:
   • einen Speicher für Variablen,
   • einen Speicher für Funktionen,
   • einen Speicher für Listen,
   • …

   Die Realisierung als Hashtabelle (Wörterbuch, Dictionary) würde sich für jeden einzelnen dieser Speicher anbieten. Eine Hashtabelle ist eine Liste von Schlüssel-Wert-Paaren, wo jeder Wert schnell über seinen Schlüssel adressiert werden kann – in obigem Fall wären folgende Zuordnungen sinnvoll:

   • [Variablenname => Variablenwert]
   • [Funktionsname => (Funktionsbeginn (Zeiger), Funktionsende (Zeiger))]
   • [Listenname => Liste]
   • …

   In meinem Studium wird mir beigebracht, alles so abstrakt wie möglich zu halten, weswegen ich die nun folgende Lösung vorschlage. Hierbei benötigen wir nur zwei Hashtabellen (plus eine geschachtelte) und haben zum einen den Vorteil, dass wir beliebige Daten speichern können, zum anderen, dass die Überprüfung auf doppelte Bezeichner (Variablen-, Funktions- und Listennamen sollten ja nur einmal vorkommen!) sehr einfach wird:

   • Wir verwenden eine Tabelle, um jedem Bezeichner einen Typ zuzuweisen. ([Bezeichner => Typ])
   • Wir verwenden eine weitere Tabelle, um jedem Typ eine weitere Hashtabelle zuzuweisen, die wiederum jeden Bezeichner mit seinem Wert verknüpft. ([Typ => [Bezeichner => Wert]])

   Mit entsprechenden Operationen auf diesen beiden Tabellen haben wir nun unsere Umgebung (Environment).

Nachdem wir das alles beantwortet haben, können wir loslegen. Aber Halt! Einen wichtigen Punkt haben wir noch nicht angesprochen: Wie verwende ich Regular Expressions so, dass ich zum einen leicht feststellen kann, welchen Anweisungstyp ich vor mir habe, und zum anderen einfach an die gewünschten Daten komme?

Das ist der Punkt, an dem wir unsere praktische Arbeit beginnen werden.

Inhalt

1. Einführung: Ein Abenteuer in Teilen
2. Der Lexer
3. Grundlagen des Parsens
4. Syntax
   

Als Beispiel sei die UVD von LastSharp gegeben, die wir im folgenden Codebeispiel mithilfe einer XSL-Transformation (DescriptionPage.xsl) in eine HTML-Datei verwandeln. Das soll illustrieren, wie einfach die Verwendung von UVD sein kann, wenn entsprechende Bibliotheken vorhanden sind:

UVD lastsharp = UVD.Create("http://dev.xscheme.de/uvd/lastsharp.uvd.xml");
lastsharp.Save("c:/lastsharp.htm", "http://dev.xscheme.de/uvd/DescriptionPage.xsl");

Nun haben wir eine Datei “lastsharp.htm”, die hier eingesehen werden kann und Beschreibungen in verschiedenen Sprachen und Längen bietet, Downloadlinks, etc… Außerdem sind (wie man bei der Ansicht des Quelltextes feststellen kann) auch die META-Tags zu Schlüsselwörtern und Beschreibungen bereits gesetzt, sodass die Seite auch für Suchmaschinen verwendbar ist.

Das UVD-Objekt (s. Code) bietet noch weitere Möglichkeiten, aber ich möchte nun auf den Update-Mechanismus zu sprechen kommen, den man mithilfe von UVD implementieren kann. Eine UVD kann einen Verweis auf die vorhergehende Version, sowie Informationen zum inkrementellen Update (lösche Datei X, aktualisiere Datei Y, …) enthalten, sodass man durch Untersuchen der Versionsgeschichte jede Version auf den neuesten Stand bringen kann.

Wir verwenden die folgenden (sinnlosen) Dateien zur Demonstration: Version 1.2 >> Version 1.1 >> Version 1.0. Mithilfe der UVDs läuft ein Update von Version 1.0 auf 1.2 folgendermaßen ab:

1. Extrahiere aus der UVD zu Version 1.2 die URL zu Version 1.1!
2. Speichere die Update-Informationen in der UVD zu Version 1.1!
3. Führe nacheinander die Update-Schritte (1.0 >> 1.1) und (1.1 >> 1.2) aus!

Die Bibliothek, an der ich gerade arbeite, verwendet hierfür sog. Update-Profile, die festlegen, welche Sprache und welches Betriebssystem für das Update berücksichtigt werden soll. Code:

UVD version12 = UVD.Create("http://dev.xscheme.de/uvd/updatetest1.xml");
UVDVersion currentVs = new UVDVersion(1, 0); // aktuelle Version
UpdateProfile profile = new UpdateProfile(); // OS und Sprache egal
Update u = profile.CreateUpdate(currentVs, version12);
foreach(UpdateSegment s in u)
{
    Console.WriteLine(s.ToString());
}
u.Execute("c:/program/"); // Programmverzeichnis muss angegeben werden!

Das liefert folgende Ausgabe:

[Add: file3.txt] http://www.download.de
[Execute: file3.txt]
[Remove: file4.txt]
[Add: file1.txt] http://www.download.de
[Update: file2.txt] http://www.download.de
[Execute: file3.txt]

Anschließend werden genau diese Schritte ausgeführt. Bei der Erstellung des Updates wird im übrigen mehr oder weniger intelligent vorgegangen: wenn eine Datei in Version 1.2 gelöscht wird, wird sie in Version 1.1 gar nicht erst hinzugefügt. Und warum eine Datei hinzufügen, wenn sie irgendwann später überschrieben wird? Dieses Verhalten lässt sich über das Update-Profil festlegen. Wenn deaktiviert, lautet die Ausgabe:

[Add: file4.txt] http://www.download.de
[Add: file2.txt] http://www.download.de
[Add: file3.txt] http://www.download.de
[Execute: file3.txt]
[Remove: file4.txt]
[Add: file1.txt] http://www.download.de
[Update: file2.txt] http://www.download.de
[Execute: file3.txt]

Soviel dazu. Was jetzt noch wichtig ist, ist die Übertragung der Bibliothek auf andere Programmiersprachen. Deswegen suche ich Entwickler, die mit mir gemeinsam UVD auf Java, PHP, etc… portieren. Bei Interesse einfach eine E-Mail schreiben an Yannick_Scherer@gmx.net! Aber man sollte sich bewusst sein, dass das einiges an Arbeit bedeutet.

Mehr habe ich vorerst nicht vorzuweisen… Außer vielleicht das ultimative “einzeilige” Update (mit einer sinnvollen Datei funktioniert es dann auch…):

new UpdateProfile()
       .CreateUpdate(new UVDVersion(1, 0), UVD.Create("http://dev.xscheme.de/uvd/updatetest1.xml"))
       .Execute("c:/program/");

Ich bin in meinem vorletzten Artikel zum Thema Update-Check bereits darauf eingegangen: Versionsänderungen sind nicht immer leicht zu verfolgen und die Überprüfung auf Updates erfordert meist einen nicht zu unterschätzenden Programmier- und Verwaltungsaufwand. Weiterhin bedeutet es für den Entwickler selbst auch, dass er auf mehreren Hochzeiten tanzen muss: er stellt meist eine eigene Downloadseite bereit, die Links zu verschiedenen Versionen enthält, er aktualisiert gleichzeitig die Dateien, die für die Versionsüberprüfung zuständig sind, er kümmert sich um die Daten, die in irgendwelchen Softwareverzeichnissen (heise, chip.de, etc…) stehen, usw., usw… Als verantwortungsvoller Entwickler mit der Ambition, sein Programm unter die Leute zu bringen, hat man richtiggehend die Pflicht, diese Schritte durchzuführen – und das regelmäßig und mit äußerster Genauigkeit.

Hier nun also das (absolut logische und vernünftige) Konzept, das die meisten Beispiele, die man im Web zu dem Thema “Update-Check” findet, implementieren:

Augenscheinliche Probleme hierbei:

• Die Verwaltung der Programmdaten läuft (beim Otto-Normal-Programmierer) meist von Hand ab, d.h. man bearbeitet die Update-Datei (die nicht, wie im Beispiel, im XML-Format vorliegen kann), lädt sie von Hand auf den eigenen Webserver und ist aus Kompatibilitätsgründen meist an ein (demnach schwer erweiterbares) Format und an einen bestimmten Dateinamen gebunden.
• Je nachdem, wie detailliert die Update-Informationen sind (nur Versionsnummer vs. Versionsnummer, Änderungsdatum, Changelog, …), kann das Bearbeiten der Versionsdatei eine Heidenarbeit bedeuten.
• Der Entwickler muss das Programm erst einmal dazu bringen, einen funktionierenden Versions-Check durchzuführen.
• Und was passiert bei Programmen, die mehrsprachig funktionieren und beworben werden?

Die Idee im erwähnten Artikel war es also, den “Update Notification Server” nicht mehr als Eigentum des Entwicklers zu sehen, sondern als über ein API zugängliche Plattform im Internet, die Verwaltungsfunktionen komfortabel bereitstellt. Gleichzeitig wären verschiedene Bibliotheken für das API nötig, um dem Programmierer die Implementierung der Versionsprüfung fast gänzlich abzunehmen.

Was folgte, war ein Einspruch.

Es sei nicht garantierbar, dass der verantwortliche zentrale Server auch in zwei Jahren noch erreichbar sein würde, wurde argumentiert. Man könne das bei einem eigenen Server viel eher kontrollieren – und außerdem habe heutzutage ohnehin jeder Entwickler zumindest ein bisschen Webspace.

Dem kann man nicht widersprechen. Zwar würde eine zentrale Plattform den Komfort steigern, allerdings unvermeidbar auch das Risiko. Was also tun?

Unvereinbarkeit

Ein großes Problem bei den vielen Versionsprüfungsimplementierungen (was für ein Wort!) im Web ist die Unvereinbarkeit. Die meisten basieren auf verschiedenen Dateiformaten, die wiederum unterschiedlichen Informationsgehalt bieten. Eine reine Textdatei mit der Versionsnummer mag dem einen reichen, der andere benötigt aber vllt. auch schon den Downloadlink für die aktuelle Version dazu. Oder gar den Namen des Programms und Zusatzmeldungen. Kann passieren.

Wenn einem schließlich keine der Lösungen des World Wide Webs zusagt, dann bleibt nichts anderes zu tun, als eine bestehende Lösung anzupassen. Oder from scratch, also komplett neu zu beginnen. Das wiederum kostet Zeit und Energie, Schweiß und Kaffee, von den Nerven gar nicht erst zu sprechen. Was also tun? (Zweimal haben wir uns das jetzt schon gefragt!)

Eine Lösung, die es allen recht macht, wird es vermutlich nie geben, aber das heißt nicht, dass man nicht versuchen darf, in ihre Nähe zu kommen. Was benötigt wird, ist ein standardisiertes Dateiformat für Softwarebeschreibungen.

Standards

Es gibt so etwas bereits unter dem Namen Portable Application Description (PAD), nachzulesen beispielsweise in Wikipedia oder der Association of Shareware Professionals, anzusehen u.a. hier. Der Vorteil: das ist in der Tat ein Standard; der Nachteil: er wurde für den Vertrieb von Shareware entworfen. Außerdem wird ein alternatives XML-Namensraumkonzept verwendet, was sich für einen solchen Standard meiner Meinung nach nicht gehört.

Aber ganz allgemein hat das Format in meinen Augen signifikante Schwächen:

• Erweiterbarkeit: Man darf genau einen Screenshot angeben, eine Informations-URL, usw…
• Es findet keine Unterscheidung nach unterstützen Betriebsystemen statt. Angenommen, es gäbe einen Installer, der das Programm auf den neueren Windows-Versionen einrichtet, sowie einen, der es sogar auf Windows 95 zum Laufen bringt: PAD bietet keine Möglichkeit, diese Dateien zu unterscheiden bzw. überhaupt erst vernünftig gemeinsam anzubieten.
• Wir leben in einer multilingualen Welt. Die meisten Programme sind für mehrere Sprachen ausgelegt, doch würde man versuchen, Informations/Download-URLs nach Sprache anzubieten, würde man an PAD absolut insane werden.
• Überhaupt fehlt so etwas wie Hinweise auf Support im Web in PAD. Man kann Telefonnummern angeben, aber das Leben und die Lebenshilfe findet heutzutage nun einmal zu größeren Teilen im Internet statt als noch früher. Und E-Mail-Adressen bedeuten bloß Wartezeit.
• Man kann in PAD genau einen Entwickler angeben. Was macht man bei heutzutage weit verbreiteten Entwickler-Teams?
• Das Format hat eine Struktur, die das Verständnis manchmal erschwert. Aber es wird ja von Computern verarbeitet, also ist das akzeptabel. Andererseits: auch Suchmaschinencrawler sind Computerprogramme, und PAD (ein Standard!) wird von denen so gut wie ignoriert!
• Was Nutzer oftmals interessiert, ist die Entwicklung eines Programms: Was gibt es neues? Was wurde entfernt, was verbessert?

Es ist vielleicht etwas hochgegriffen, aber für die Softwarebeschreibung der heutigen Zeit muss ein neuer Standard erarbeitet werden. Und hier wird aus dem Gedankenspiel der Versuch.

Was macht Software aus?

Um welche Punkte müsste sich ein neues Format kümmern, was sind seine Prämissen und Ziele? Und was genau will ich eigentlich? Ein Brainstorming:

• Sprachenunterstützung
• Änderungsverfolgung
• Autorenliste
• Firmenkontaktdaten
• Lizenzinformationen
• Suchmaschinen-Metadaten
• Installationsanweisungen
• Abhängigkeiten: Was brauche ich, damit das Programm läuft?
• Einfacher Zugang zu Support-Quellen (Foren, Anleitungen, FAQ)

Es entwickelt sich vor meinem inneren Auge also langsam eine XML-Struktur, die das alles mit sich bringt: XML Application Description (XAD), veranschaulicht durch ein Beispiel (Rechtsklick >> Quelltext), das verwendete XSLT-Stylesheet und die DTD (das Dokument ist valide, ich weiß nicht, warum Firefox und der IE da rumspinnen).

Ein Gedanke

Dann kam mir ein Gedanke: nicht nur Programme unterliegen Änderungen, auch Dokumente, Filme, Serien lassen sich einem Versionskonzept unterordnen. Zwei Beispiele: die FAZ vom 30.04.2009 könnte ebensogut die Versionsnummer 2009.119 (der 30.04. ist der 119. Tag des Jahres 2009) tragen, und die Special Extended Edition von “Herr der Ringe: Die zwei Türme” könnte auch “Herr der Ringe 2.1″ heißen (wenn man keinen Wert auf Gewinn legen würde). Mit ein wenig Phantasie überträgt man das ganze auf Autos, CPUs, kurz gesagt: alles, was sich irgendwie als bildlicher Entwicklungsstrom darstellen lässt.

Wichtig hierbei ist die Möglichkeit, stets auf die früheren Versionen eines Objektes zugreifen zu können, weil im Idealfall Verweise auf diese vorhanden sind.

Wenn man also das oben erwähnte Format weiterentwickelt, verallgemeinert und anpasst, dann hat man ein mächtiges Werkzeug für weit mehr als bloß Software. Und hier wären wir.

Universal Version Description (UVD)

Da die Verwendung nicht mehr nur auf Programme beschränkt ist, ist es wichtig, anzugeben, was genau in einem Dokument beschrieben wird. Die Nomenklatur hierfür wäre idealerweise etwas wie “Kategories:Unterkategorie” oder “Kategorie” allein. Beispiele:

• media:tv-episode
• software:utility
• paper:specification
• paper:mathematics
• …

Folgendes wäre ein Beispiel für das kleinstmögliche UVD-Dokument:

<?xml version="1.0"?>
<!DOCTYPE uvd SYSTEM "http://dev.xscheme.de/uvd/uvd-1.dtd">
<uvd version="1.0.0" type="software:audio">
  <general>
    <name>WinAmp</name>
  </general>
</uvd>

Nicht sehr aussagekräftig, aber jetzt bauen wir noch Informations-Links (in verschiedenen Sprachen), sowie Beschreibungstexte (in verschiedenen Sprachen und Längen; die unterstützen Längenangaben sind 100, 255, 2000 und “any”) ein:

<?xml version="1.0"?>
<!DOCTYPE uvd SYSTEM "http://dev.xscheme.de/uvd/uvd-1.dtd">
<uvd version="1.0.0" type="software:audio">
  <general>
    <name>WinAmp</name>
    <urls>
      <url lang="en">http://www.winamp.com/</url>
      <url lang="de">http://de.winamp.com/</url>
    </urls>
    <descriptions>
      <description lang="en" maxlength="255">
        WinAmp is a multimedia player, supporting (...)
      </description>
      ...
    </descriptions>
  </general>
</uvd>

Deutsch und Englisch vorhanden, alles andere beliebig nachtragbar. Weitere Informationen wären: Lizenz, Keywords, Screenshots, etc…Anschließend könnte in einem neuen Abschnitt “release” die aktuelle Version (inkl. Downloadlinks nach Sprache und OS) beschrieben, in “contributors” alle Beteiligten aufgelistet und in “company” Informationen zum Firmenkontakt bereitgestellt werden.

Eine komplette Dokumentation des Formats würde den Rahmen aber noch mehr sprengen, deswegen wird hier auf die folgenden Dokumente verwiesen:

• “Spezifikation” zu UVD: http://dev.xscheme.de/uvd/Universal%20Version%20Description.txt
• DTD: http://dev.xscheme.de/uvd/uvd-1.dtd (Validate)
• Beispiele:
  • Programm-Release
  • Dokument
  • TV-Episode

Fazit

Meistens ist der eigene Blick von Selbstherrlichkeit getrübt, wenn man etwas in den eigenen Augen neues und tolles geschaffen hat. Deswegen brauche ich Meinungen hierzu.

Um das anfangs erwähnte Argument noch einmal aufzugreifen, man könne seinen eigenen Webspace besser kontrollieren, will ich hier erwähnen, dass ein UVD-Dokument natürlich überall liegen kann. Was bisher fehlt, sind Programme zur Verwaltung und Erstellung, sowie Bibliotheken zur Verarbeitung.

Vielleicht überschätze ich auch den Nutzen des ganzen. Kein Grund allerdings, den Stein nicht ins Rollen zu bringen.

Update (02.05.2009)

Ich will an dieser Stelle noch demonstrieren, wie sich das Format für einfache Versionsprüfung, sowie Update-Verarbeitung eignet.

Für einen normalen Versionscheck würde schon so etwas reichen:

<uvd version="1.0.0" type="software:ripper">
  <general>
    <name>LastSharp</name>
  </general>
  <release>
    <date>
      <day>20</day>
      <month>4</month>
      <year>2009</year>
    </date>
    <version>
      <major>0</major>
      <minor>4</minor>
      <build>1</build>
    </version>
  </release>
</uvd>

Und folgende Datei könnte von einem Updater automatisch verarbeitet werden:

<uvd version="1.0.0" type="software:ripper">
  <general>
    <name>LastSharp</name>
  </general>
  <release>
    <date>
      <day>20</day>
      <month>4</month>
      <year>2009</year>
    </date>
    <version>
      <major>0</major>
      <minor>4</minor>
      <build>1</build>
    </version>
    <files>
      <file name="LastUtility" os="any" type="lib" filename="LastUtility.dll"
            update-action="update" update-path=".inc" direct-download="no">
        <urls>
          <url lang="all">http://download.server.tld/LastUtility.dll</url>
        </urls>
      </file>
      <file name="LastSharpExe" os="any" type="exe" filename="LastSharp.exe"
            update-action="update" direct-download="no">
        <urls>
          <url lang="all">http://download.server.tld/LastSharp.exe</url>
        </urls>
      </file>
      <file name="SettingsFile" os="any" type="xml" filename="settings.xml"
            update-action="remove" />
      <file name="LastSharpFull" os="any" type="package" filename="LastSharp041.zip"
            update-action="ignore">
        <urls>
          <url lang="all">http://download.server.tld/LastSharp041.zip</url>
        </urls>
        <descriptions>
          <description lang="de" maxlength="any">
            Das vollständige Paket mit allen Dateien von LastSharp 0.4.1.
          </description>
        </descriptions>
      </file>
    </files>
  </release>
</uvd>

Wenn man genau hinsieht, erkennt man die Anweisungen an den Updater:

1. Lade die Datei “LastUtility.dll” von der angegebenen URL herunter und überschreibe ihre Entsprechung im Unterverzeichnis “.inc”.
2. Tue dasselbe mit der Datei “LastSharp.exe”, allerdings diesmal im Hauptverzeichnis. (“update-path” fehlt)
3. Lösche die Datei “settings.xml” im Hauptverzeichnis.

Der letzte “file”-Eintrag enthält das Gesamtpaket, das beim automatischen Update ignoriert wird. (“update-action=’ignore’”) Gleichzeitig wird es aber dem User im Gegensatz zu den Dateien zuvor direkt zugänglich gemacht. (“direct-download=’no’” soll verhindern, dass evtl. Clients die so markierten Links dem User zeigen)

Wenn man jetzt bedenkt, dass ein wichtiger Punkt von UVD die Verlinkung mit den früheren Versionen ist (Der “release”-Tag bietet das Attribut “previous”, das auf das entsprechende UVD-Dokument verlinkt!), sieht man schnell, dass man mit diesem Format jede beliebige Version aktualisieren kann, wenn man sich in der Versionsgeschichte “zurückhangelt”.

Ich hoffe, diese kleine Demonstration hat noch einmal verdeutlicht, worin ich u.a. den Nutzen des Formats sehe.

Um zu lernen, wie das geht, entwickeln wir hier (mit C#, aber eine Übertragung auf andere .NET-Sprachen dürfte jeder einigermaßen versierte Programmierer hinbekommen) ein Mini-Programm, das in einem Fenster zwei Eingabefelder für “Interpret” und “Titel” bereitstellt und das zugehörige Album findet. Ich gebe zu, keine bahnbrechende Idee, aber zur Demonstration reicht’s.

Zuallererst erstellen wir ein neues Projekt vom Typ “Windows Forms Anwendung” mit beliebigem Namen und erstellen einen Verweis auf Lapicon. Das geht folgendermaßen:

1. Rechtsklick auf “Veweise” im Projektmappen-Explorer, dann Klick auf “Verweis hinzufügen…”:
2. Unter “Durchsuchen” die Datei “Lapicon.exe” suchen und auswählen. Klick auf “OK”.

Jetzt kann die Programmentwicklung losgehen. Wir erstellen ein Fenster, das in etwa so aussieht:

Jetzt geht es an die Implementierung der Funktionen. Alle Lapicon-Funktionen werden durch das Objekt “LapiconProcessor” im Namespace “Lapicon” bereitgestellt. Da “LapiconProcessor” ein ziemlich langer Name ist und Programmierer von Haus aus faul sind, fügen wir folgendes Statement an den Anfang des Codes unseres Fensters (Rechtsklick auf das Fenster >> “Code anzeigen”) ein:

using L = Lapicon.LapiconProcessor;

Damit kürzen wir das Objekt “LapiconProcessor” als “L” ab und können ab sofort in unserem Code darauf zugreifen. Zuallererst ist unsere Anwendung ja auf das Last.FM-API ausgelegt, d.h. beim Laden der Anwendung würde es sich anbieten, Lapicon für dieses API zu konfigurieren. Hierfür verwenden wir das “Load”-Ereignis des Fensters, indem wir an irgendeine freie Stelle (im Fensterentwurf) doppelklicken. Anschließend ergänzen wir den so erstellten Code folgendermaßen:

private void AlbumFinderForm_Load(object sender, EventArgs e)
{
   // Lapicon: Initialisierung für Last.FM (entspricht L.Process("#lastfm"))
   L.LastFMInit(); 
}

Jetzt müssen wir noch festlegen, was passiert, wenn wir auf den Button klicken. Also erstellen wir mit einem Doppelklick darauf das “Click”-Event und verwenden die verschiedenen Lapicon-Funktionen, um eine Anfrage an Last.FM zu senden und das Ergebnis in einer MessageBox anzuzeigen. Die wichtigsten Lapicon-Funktionen sind:

• Process(“statement1″, “statement2″, …) führt die angegebenen Lapicon-Befehle nacheinander aus.
• Var(“var”) liefert den Wert einer Variablen.
• Var(“var”, “wert”) speichert “wert” in der Variable “var”.
• VarExists(“var”) liefert “true”, wenn eine Variable existiert.
• List(“var”) liefert eine Liste.
• ListCreate(“var”) erstellt eine Liste.
• List(“var”, “wert”) fügt “wert” zur Liste hinzu.
• ListExists(“var”) liefert “true”, wenn eine Liste existiert.

Mehr braucht man meistens nicht. Unser Click-Event wird demnach folgendermaßen aussehen:

private void btFindAlbum_Click(object sender, EventArgs e)
{
    // Interpret und Titel
    string artist = txtArtist.Text.Trim();
    string track = txtTrack.Text.Trim();

    // Wenn eins von beidem leer ist: nicht weitermachen
    if (artist == "" || track == "") return;

    // Ansonsten: Album (und richtig geschriebene Infos) holen
    L.Process(
        "[track.getInfo : track=" + track + "&artist=" + artist + "]",
        "store track/album/title in album",
        "store track/artist/name in artist",
        "store track/name in track"
    );

    // Ausgabe oder Fehler
    if (L.Var("album") == "")
    {
        MessageBox.Show(
            "Kein Album zu diesen Eingaben gefunden!",
            "Kein Album",
            MessageBoxButtons.OK,
            MessageBoxIcon.Exclamation);
    }
    else
    {
        MessageBox.Show(
            "Gefundene Informationen:\n\n" +
               "   " + L.Var("artist") + " - " + L.Var("track") + "\n" +
               "   Album: " + L.Var("album"),
            "Album gefunden!",
            MessageBoxButtons.OK,
            MessageBoxIcon.Information);
    }
}

Das war auch schon alles. Mit “Process” wird die Anfrage abgeschickt und die nötigen Daten gesichert, mit “Var” erfolgt die Verwendung der Daten. Und schon ist das Programm good to go:

Viel einfacher geht es wirklich nicht mehr. Ich hoffe, damit allen, die Interesse an Lapicon haben, ein Stück weiter geholfen zu haben.

Praktisch gesehen ist Lapicon eine einfache Möglichkeit, Webservices zu verwenden. Und geeignete gibt es (wie die Google-Suche nach “REST-API” schon bald zeigt) einige:

• Last.FM (http://www.last.fm/api)
• Flickr (http://www.flickr.com/services/api/)
• Twitter (http://apiwiki.twitter.com/Twitter-API-Documentation)
• Wuala (http://www.wuala.com/de/api)
• …

Aber wie geht man nun vor, wenn man Lapicon für irgendeines dieser APIs verwenden will? Diese Frage will ich in diesem Artikel beantworten, anhand zweier Beispiele: den Skripts DownloadAlbumAfterSearch.lpc und Lyrics.lpc aus dem Paket DarkSharpScripts, das ab Version 1.0.9 von Lapicon im Verzeichnis “packages” zu finden ist. Das erste Script sucht anhand einer Eingabe alle in Frage kommenden Alben und lässt den User eines auswählen, das anschließend komplett von Last.FM heruntergeladen wird (wenn möglich). Und das zweite findet mithilfe der LyricWiki (noch eine Seite, die REST-Anfragen unterstützt!) den Songtext zu einem vom User eingegebenen Musiktitel.

Schritt 0: Den einfachen Scriptstart ermöglichen

Damit man möglichst einfach Lapicon-Scripts starten kann, sollte man eine Datei mit der Endung “.lpc” anlegen und unter Windows darauf doppelklicken und anschließend über “Programm aus Liste auswählen” >> “Durchsuchen…” die Lapicon.exe als Standardprogramm festlegen. Dann lassen sich Scripts per Doppelklick starten.

Schritt 1: Grundeinstellungen

Zuallererst muss Lapicon mitgeteilt werden, wohin es Anfragen schicken soll, wie diese Anfragen aussehen sollen und wie es mit den Antworten umzugehen hat. Man stelle sich folgende Fragen:

1. Wie lautet die URL, an die die Anfragen gehen sollen? (Findet man meistens auf der API-Seite.)
2. Brauche ich irgendwelche Daten für die Anfrage, die immer vorhanden sein müssen? (Beispielsweise bei Last.FM: ein API-Schlüssel.)
3. Wie ist das Format der Anfrage-URL? “URL?Parameter” oder “URL/Parameter1/Parameter2″?
4. Wie sieht die Antwort aus? Welcher XML-Knoten ist die Wurzel? Sind irgendwelche Namespaces enthalten?
5. Werden mir Informationen bereitgestellt, ob Fehler aufgetreten sind, und wo finde ich sie?

Jetzt geht es ans Konfigurieren von Lapicon, hier am Beispiel Last.FM:

// s.o. Punkt 1: die Basis-URL
#base http://ws.audioscrobbler.com/2.0/

// s.o. Punkt 2: API-Key muss immer mitgesendet werden
#static api_key ce59c153ff5e3003c74df5b618aeccac

// s.o. Punkt 3: Die Anfrage hat das Format "URL?Parameter" (ansonsten: #noquery)
#query

// s.o. Punkt 4: Wurzel ist der "lfm"-Knoten; wir brauchen die Namespaces "xspf" und "lastfm"
#rootnode
#namespace xspf http://xspf.org/ns/0/
#namespace lastfm http://www.audioscrobbler.net/dtd/xspf-lastfm

// s.o. Punkt 5: wenn kein Fehler aufgetreten ist, steht im Attribut "status" des "lfm"-Knotens "ok"
#errornode lfm/@status
#noerrorvalue ok

Für “#rootnode” und “#errornode”, sowie später für Anfragen, wird Kenntnis von XPath benötigt. Es sei an dieser Stelle auf den Wikipedia-Artikel zum Thema verwiesen.

Da Last.FM als eines der Hauptanwendungsfelder für Lapicon gedacht war, lässt sich das oben geschriebene abkürzen:

#lastfm

Und schon ist Lapicon bereit dafür, zu arbeiten.

Schritt 2: Wie soll das Programm ablaufen?

Es ist immer wichtig, sich klarzumachen, was man jetzt eigentlich vorhat. Was also soll unser Script machen? Welche Daten brauchen wir dafür? Welche Anfragen müssen wir senden und welche Teile der Antworten verwenden?

Wir schreiben ein Script, das Alben sucht und anschließend komplett herunterlädt, also soll es folgende Schritte ausführen:

1. Eingabe des Suchstrings
2. Verwendung der Funktion album.search des Last.FM-APIs um eine Suche durchzuführen. Aus der Antwort lesen wir die Titel, Interpreten und IDs der einzelnen Alben aus.
3. Ausgabe einer nummerierten Liste mit Interpreten und Albumtitel
4. Eingabe der Nummer des gewünschten Albums
5. Verwendung der Funktion playlist.fetch, um an die Tracks des Albums zu kommen. (Mit zwei nicht dokumentierten Parametern.) Wir verwenden die URLs und die Titel der Tracks.
6. Erstellen des Ausgabeverzeichnisses nach dem Muster “Interpret/Album”
7. Schleife, die einen Track nach dem anderen herunterlädt.
8. Ende.

Schritt 3: Implementierung

Das Originalscript setzt zuerst die Last.FM-Einstellungen fest, dann lädt es die DarkSharpScripts-Konfigurationsdatei, die im selben Verzeichnis liegt:

// Use Last.FM
#lastfm

// Include
inc(<script directory>/Config.DarkSharpScripts.lpc)

Anschließend folgt die Eingabe des Suchstrings und eine Prüfung, ob auch wirklich etwas eingegeben wurde:

// Search
def query << Suchen
echo

[if <query> is not empty]

Die Zeile “def query << Suchen” bewirkt, dass der User eine Eingabezeile mit der Beschriftung “[in] Suchen:” vor sich hat. Drückt er die Enter-Taste wird alles eingegebene in der Variable “query” gespeichert. Um auf den Wert dieses Variable wiederum zuzugreifen, muss man sie in spitze Klammern setzen: “<query>”. Alles, was jetzt folgt, wird demnach nur ausgeführt, wenn der Wert von “query” nicht leer ist:

   [album.search : album=<query>&limit=<DS_SearchLimit>]*
   store* results/albummatches/album/name in albumTitles
   store* results/albummatches/album/artist in albumCreators
   store* results/albummatches/album/id in albumIDs

   // Choose
   f:displayAlbum n
      echo [<n>] <albumCreators[<n>]> - <albumTitles[<n>]>
   f:end
   forall* albumTitles index t: displayAlbum(<t>)
   echo

Das Konstrukt in eckigen Klammern ist die Anfrage an Last.FM. Vor dem Doppelpunkt steht die Funktion, die aufgerufen werden soll, dahinter ihre Argumente – in diesem Fall “album” und “limit” mit den Werten der Variablen “query” und “DS_SearchLimit” (letztere aus der Konfigurationsdatei; sie legt fest, wie viele Suchergebnisse maximal angezeigt werden). Die Sternchen signalisieren, dass nun nicht ein einzelner Wert gespeichert werden soll, sondern eine Reihe von Werten in einer Liste. “store* results/albummatches/album/name in albumTitles” beispielsweise speichert alle Werte, die über diesen XPath (“results/…”) zu erreichen sind, in der Liste “albumTitles”.

Was dann folgt, ist eine Funktion, die genau einen Wert (die Variable “n”) als Argument erhält. Sie gibt anhand der beiden Listen “albumTitles” und “albumCreators” das n-te Album (wobei n bei 0 beginnt) aus. Hier sieht man den Zugriff auf einzelne Listenelemente: <albumTitles[0]> wäre z.B. der Titel des ersten gefundenen Albums, falls vorhanden.

Diese Funktion wird nun für jedes Element der Liste “albumTitles” aufgerufen, immer mit dem aktuellen Index als Argument. (Neben der gezeigten Version der “forall*”-Schleife gibt es noch eine weitere, die nicht den Index, sondern den Wert als Variable liefert: “forall* list as element: …”)

Jetzt kann der User eingeben, welches Album er haben will, anschließend wird die Playlist mit den einzelnen Titel geladen:

   def nr << Nummer des Albums
   echo

   // Album Info
   def albumID = <albumIDs[<nr>]>
   def albumName = file(<albumTitles[<nr>]>)
   def albumCreator = file(<albumCreators[<nr>]>)

   // Playlist Info
   [playlist.fetch : playlistURL=lastfm://playlist/album/<albumID>&streaming=1&fod=1]*
   store* xspf:playlist/xspf:trackList/xspf:track/xspf:title in trackTitles
   store* xspf:playlist/xspf:trackList/xspf:track/xspf:location in trackLocation

Die Zeile “def albumName = file(…)” speichert in der Variable “albumName” einen bereinigten, für Dateinamen geeigneten String. Jetzt haben wir die URLs und Titel der Tracks, die wir herunterladen wollen. Und genau das macht der folgende Abschnitt – wieder nach dem Prinzip: “Lade die Datei mit dem Index “index” herunter!”

   [if <trackLocation length> != 0]

      // Directory
      def dir = <DS_AlbumsPath><albumCreator>/<albumName>
      mkdir <dir>

      // Download Function
      f:dl index
         def title = file(<trackTitles[<index>]>)
         def nindex
         nindex ::= <index>+1
         echo Downloading(<nindex>/<trackLocation length>) <albumCreator> - <title>...
         def fn = <dir>/<nindex> - <albumCreator> - <title>.mp3
         lpc(<script directory>/ResolveAndDownload.lpc) with <trackLocation[<index>]>|<fn>
         mp3Gain(<fn>)
      f:end

      // Download
      forall* trackTitles as t: dl(<trackTitles counter>)
      //
      wait

   [else]

      wait Album nicht herunterladbar

   [endif]

[else]

   wait Keine Sucheingabe

[endif]

Wir sehen einiges Neues hier: die Funktion “mkdir” erstellt ein Verzeichnis, die Zuweisung mit “::=” löst eine Berechnung aus (damit “nindex” um 1 größer ist als “index”) und dann das Konstrukt “lpc(…) with …”. Hier geschieht folgendes: Lapicon ruft das Script ResolveAndDownload.lpc auf, das im selben Verzeichnis liegt, und zwar mit den Kommandozeilenargumenten <trackLocation[<index>]> und <fn>. Dieses kleine Hilfsscript macht nichts anderes, als die übergebene URL (das erste Argument) mithilfe von HTTP aufzulösen und dann herunterzuladen. Das zweite Argument ist der Name der heruntergeladenen Datei. Es sollte sich also eigentlich von selbst erschließen:

// Data
def url = <cmd 1>
def file = <cmd 2>

// Resolve
def rurl

#error off
rurl = resolve <url>
#error on

[if <rurl> is not empty]

   down <rurl> >> <file>

[else]

   echo Resolving URL "<url>" failed...
   echo
   wait Taste drücken zum Beenden
   exit

[endif]

Die Funktion “mp3Gain”, die nach dem “lpc”-Statement kommt, ist in der Konfigurationsdatei definiert und ruft ein Hilfsprogramm auf, das wiederum mit der mp3Gain.exe,  die im selben Verzeichnis liegt, die Musikdatei normalisiert:

// MP3-Gain
f:mp3Gain file

   [if <file> is not empty]

      echo Normalisieren...
      shell: <script directory>/ExecuteMp3Gain.bat | "<file>"

   [endif]

f:end

Eine genaue Übersicht über alle von Lapicon unterstützen Funktionen findet sich in der Datei Lapicon.txt oder auf SourceForge: http://lastsharp.svn.sourceforge.net/viewvc/lastsharp/branches/Lapicon/Lapicon.txt?view=markup&pathrev=65

Beispiel 2: Lyrics.lpc

// -------------------------------------------------------------------
// DarkSharp.Lyrics
//   Downloads lyrics
//   Copyright (c) 2009 Yannick Scherer
// -------------------------------------------------------------------
// Lyricwiki
#base http://lyricwiki.org/api.php
#rootnode LyricsResult
#static func getSong
#static fmt xml

// Config
inc(<script directory>/Config.DarkSharpScripts.lpc)

// Input
def artist << Interpret
def track << Titel

// Get Lyrics from Lyricwiki
[artist=<artist>&song=<track>] store lyrics in lyrics

[if <lyrics> is not empty]
   // Clean
   artist = file(<artist>)
   track = file(<track>)
   // Save
   mkdir <DS_LyricsPath>
   echo crlf(<lyrics>) >>> <DS_LyricsPath><artist> - <track>.txt
[else]
   echo Keine Lyrics gefunden!
[endif]

echo
wait

Anmerkungen hierzu: man kann Anfragen auch in einer Zeile und/oder ohne Angabe der Funktion schreiben. Letzteres ist immer dann notwendig, wenn der Parameter, der die Funktion enthält, nicht “method” heißt.

Des weiteren sieht man eine Dateiausgabe: zuerst wird mit “artist = file(<artist>)” der Interpret und anschließend der Titel bereinigt, dann wird ein Verzeichnis erstellt und anschließend eine Ausgabe in eine Datei getätigt. Das Einschließen der Lyrics in “crlf(…)” bewirkt, dass Zeilenumbrüche richtig umgesetzt werden; das Verwenden von “>>>” statt “>>” zwingt Lapicon, eine evtl. vorhandene Datei zu überschreiben, anstatt an deren Ende etwas anzuhängen.

Das Nachvollziehen der Grundeinstellungen bleibt jedem selbst überlassen.

Ich hoffe, damit konnte ich ein wenig helfen, wenn es um die Arbeit mit Lapicon geht!

Es ist ein Problem beim TuneIn aufgetreten:
There is not enough content provided by Last.FM to play the station. If this is your playlist, fill it up. Otherwise (or if this message keeps appearing), wait or try another station.

Das ist kein Problem, das von LastSharp verursacht wird, sondern hat mit Last.FM bzw. dessen Verhalten bei Playlistabfragen zu tun. Im Folgenden will ich versuchen, meine Erkenntnisse zusammenzufassen.

Man betrachte die Last.FM-FAQ zum Thema “Musik hören auf  Last.FM”:

Du kannst Playlisten anhören, wenn du ein Abonnent bist. Um eine Playlist anzuhören – deine eigene oder die eines anderen Benutzers – gehe zu der Seite der jeweiligen Playlist (zum Beispiel in deiner eigenen Musiksammlung) und klicke dort den Button “Spiele diese Playlist”. Playlisten werden immer mit zufälliger Titelreihenfolge wiedergegeben, und sie müssen mindestens 45 Titel von 15 Künstlern enthalten, bevor du sie spielen kannst.

Beachte: Playlisten können derzeit nur auf der Website, nicht im Softwareplayer wiedergegeben werden.

Falls du kein Abonnent bist, kannst trotzdem deine eigenen Playlisten erstellen, aber du kannst sie dir nicht als solche anhören. Deine neueste Playlist wird in dem Player auf deiner Profilseite erscheinen, wo die Titel von dir oder anderen Leuten, die dein Profil besuchen, einzeln gespielt oder angespielt werden können.

Zur Illustration: das Last.FM-Widget verwendet folgende URL, um an die Playlist zu kommen:

lastfm://playlist/[PlaylistID]/shuffle

Verwendet man diese URL als Nicht-Abonnent, erhält man die Meldung, dass diese Radiostation nur für Abonnenten zugänglich ist. (Fehlercode 5)

In LastSharp wird also bei Nicht-Abonnenten das “/shuffle” am Ende weggelassen, was Last.FM dazu bringt, dennoch die richtige Playlist zu senden. Allerdings erscheint schon bald der o.g. Fehler, wenn man mit dem Herunterladen beginnt – wahrscheinlich bemerkt Last.FM, dass da etwas im Gange ist, was eigentlich nicht erlaubt wäre. Stellt sich die Frage, warum man es nicht von vornherein unterbindet.

Antwort siehe oben: “Deine neueste Playlist wird in dem Player auf deiner Profilseite erscheinen, wo die Titel von dir oder anderen Leuten, die dein Profil besuchen, einzeln gespielt oder angespielt werden können.” Man kann also als Nicht-Abonennt nicht gezielt die eigene Playlist anhören, sondern nur, wenn sie auf der eigenen Profilseite erscheint. Und wie macht das Widget das dann? So: Inside Last.FM: Bestimmten Titel direkt downloaden

Ich stelle also die Frage: Sollte man die Widget-Methode in LastSharp implementieren, damit auch Nicht-Abonnenten ihre Playlist herunterladen können – auf die Gefahr hin, LastSharp ein wenig fragwürdiger erscheinen zu lassen, was Legalität angeht?

Es ist möglich, Titel vollständig, ganz gezielt und ohne Anmeldung von Last.FM herunterzuladen!

Hierfür verwendet man zwei Funktionen des APIs: track.getInfo und playlist.fetch. Die erste holt die Last.FM-ID des Titels, die zweite findet die Download-URL. Und zwar folgendermaßen:

Ausgehend von Interpret und Titel rufen wir via REST die Funktion track.getInfo auf:

http://ws.audioscrobbler.com/2.0/?method=track.getinfo&api_key=[APIKey]&artist=[Interpret]&track=[Titel]

Also z.B. “The Ballad of the RAA” von “The Rural Alberta Advantage” mit dem auf der API-Seite angegebenen Key:

http://ws.audioscrobbler.com/2.0/?method=track.getinfo&api_key=b25b959554ed76058ac220b7b2e0a026&artist=the+rural+alberta+advantage&track=the+ballad+of+the+raa

Wir erhalten folgende Antwort (XML):

<?xml version="1.0" encoding="utf-8"?>
<lfm status="ok">
<track>
    <id>170204242</id>
    <name>The Ballad of The RAA</name>
    <mbid></mbid>
    <url>http://www.last.fm/music/The+Rural+Alberta+Advantage/_/The+Ballad+of+The+RAA</url>
    <duration>207000</duration>
    <streamable fulltrack="1">1</streamable> 
    <listeners>2310</listeners>
    <playcount>12794</playcount>
    <artist>
        <name>The Rural Alberta Advantage</name>
        <mbid></mbid>
        <url>http://www.last.fm/music/The+Rural+Alberta+Advantage</url>
    </artist>
    ...
</track>
</lfm>

Uns interessieren die beiden hervorgehobenen Stellen: die erste liefert die gesuchte ID, die zweite sagt uns, ob der Track in voller Länge anhörbar ist. Nur wenn diese Zeile genau so (fulltrack=”1″) aussieht, funktioniert die hier beschriebene Methode!

Jetzt rufen wir playlist.fetch mithilfe dieser ID auf, indem wir die Playlist “lastfm://playlist/track/[ID]” verlangen:

http://ws.audioscrobbler.com/2.0/?method=playlist.fetch&api_key=[APIKey]&playlistURL=lastfm://playlist/track/[ID]&streaming=1&fod=1&api_sig=[Signatur]&sk=[Session]

MD5(api_key[APIKey]fod1methodplaylist.fetchplaylistURLlastfm://playlist/track/[ID]
sk[Session]streaming1[APISecret])

Der Parameter “streaming=1″ ist wichtig, da nur so auch der Pfad zur entsprechenden Datei übermittelt wird; “fod=1″ erweitert anscheinend unsere Zugriffsberechtigung von “Vorschau” auf “Ganzer Titel, falls verfügbar”. Für unseren Titel senden wir also

http://ws.audioscrobbler.com/2.0/?method=playlist.fetch&api_key=b25b959554ed76058ac220b7b2e0a026&playlistURL=lastfm://playlist/track/170204242&streaming=1&fod=1&api_sig=…&sk=…

und erhalten als Antwort so etwas wie:

<?xml version="1.0" encoding="utf-8"?>
<lfm status="ok">
<playlist version="1" xmlns="http://xspf.org/ns/0/">
<title>The Ballad of The RAA</title>
<creator>lastfm</creator>
<link rel="http://www.lastfm/allflp"></link>
<trackList>
    <track>
        <location>http://play.last.fm/anon/84c5974616cab2aadc698096893ee9d7.mp3</location>
        <id>170204242</id>
        <title>The Ballad of The RAA</title>
        <album></album>
        <creator>The Rural Alberta Advantage</creator>
        <duration>207000</duration>
        <extension application="http://www.last.fm">
            <fullduration>207000</fullduration>
            <trackauth>9c1a1</trackauth>
            <artistpage>http://www.last.fm/music/The+Rural+Alberta+Advantage</artistpage>
            <albumpage></albumpage>
            <trackpage>

http://www.last.fm/music/The+Rural+Alberta+Advantage/_/The+Ballad+of+The+RAA

            </trackpage>
            <buyTrackURL>...</buyTrackURL>
            <buyAlbumURL>...</buyAlbumURL>
            <freeTrackURL></freeTrackURL>
            <fodlimit></fodlimit>
            <license>arp</license>
        </extension>
        <image>http://userserve-ak.last.fm/serve/126s/19603485.jpg</image>
    </track>
</trackList>
</playlist>
</lfm>

Und voilà, die hervorgehobene Zeile zeigt uns, wo wir die gesuchte Datei finden. Ist der Track nicht vollständig abspielbar erhalten wir immerhin die 30-Sekunden-Vorschau, aber wer will die schon…

Nun, das sind genug Informationen, dass jeder, der ein wenig Ahnung von Programmierung hat, sich einen eigenen Client zusammenbasteln kann, der gezielt bestimmte Titel herunterlädt. Auch eine Website ließe sich ohne weitere Probleme aufbauen, die zu den Eingaben “Interpret” und “Titel” die entsprechende URL findet.

Ich brauche Meinungen dazu…

P.S.:  The Rural Alberta Advantage ist eine Indie-Band aus Kanada, die meiner Meinung nach Unterstützung verdient hat. Dementsprechend habe ich mir auch auf der Website der Band deren Album “Hometowns” gekauft. Sehr zu empfehlen!

Update (22.04.2009): Diese Methode habe ich als eines der Beispiel-Scripts für Lapicon implementiert.

Update (05.08.2009):
Last.FM hat einige Änderungen durchgeführt, die die Verwendung dieser Methode für jeden, der sie von Hand anwendet, sehr erschweren. Eine Implementierung in einem Programm wäre aber ohne weiteres möglich. (Es gibt meines Wissens auch einige Programme, die bisher auf diesem Weg an Musik gekommen sind. Die werden bestimmt angepasst. Nur bevor jemand mich darum bittet, sowas zu schreiben^^)