Es stellt sich zuerst die Frage: Was wollen wir? Ich für meinen Teil würde z.B. gerne wissen, wo und wann Kasabian demnächst Konzerte geben (Nicht, dass die Chance bestünde, das München auf der Liste wäre, aber dennoch…), und somit böte sich der API-Aufruf artist.getEvents zur näheren Betrachtung an: Welche Parameter hat er, wie muss er ausgeführt werden und wie sieht die Antwort aus?

Wir sehen, dass es zwei Parameter gibt (“artist” und “api_key”, beide benötigt) und dass die Antwort ein XML-Dokument ist, dass die Wurzel “lfm” hat, anschließend den Knoten “events” und viele Kindknoten “event”, die die einzelnen Konzerte enthalten. Diese wiederum besitzen Werte für die auftretenden Künstler, den Ort, die Zeit, Ticketverkäufe, etc… Das Beispiel von der API-Seite:

<events artist="Cher" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" total="4">
<event>
    <id>599858</id>
  <title>Cher</title>
  <artists>
    <artist>Cher</artist>
    <headliner>Cher</headliner>
  </artists>
  <venue>
    <name>The Colosseum at Caesars Palace</name>
    <location>
      <city>Las Vegas</city>
      <country>United States</country>
      <street></street>
      <postalcode></postalcode>
      <geo:point>
         <geo:lat>36.2265501474709</geo:lat>
         <geo:long>-115.0048828125</geo:long>
      </geo:point>
      <timezone>PST</timezone>
     </location>
    <url>http://www.last.fm/venue/8841108</url>
  </venue>
  <startDate>Sat, 16 Aug 2008</startDate>
  <startTime>19:30</startTime>
  <description></description>
  <image size="small">...</image>
  <image size="medium">...</image>
  <image size="large">...</image>
  <attendance>42</attendance>
  <reviews>0</reviews>
  <tag>lastfm:event=669027</tag>
  <url>http://www.last.fm/event/599858</url>
  <website>http://...</website>
  <tickets>
    <ticket supplier="...">http://...</ticket>
    ...
  </tickets>
</event>
...
</events>

SharpConnect stellt die folgenden Klassen zur Verfügung:

• SharpConnect.Apitizer.Apitizer bzw. SharpConnect.Xml.XmlApitizer zur Verwaltung von Methoden
• SharpConnect.Apitizer.Method zur Darstellung von Methoden
• SharpConnect.Apitizer.Parameters zur Darstellung von Parametern
• SharpConnect.Apitizer.Accessor als Zugriffsklasse für Antworten
• SharpConnect.Apitizer.Rule bzw. SharpConnect.Xml.XmlRule zur Darstellung von Accessor-Regeln
• SharpConnect.Apitizer.Codec bzw. SharpConnect.Xml.XmlCodec zur Umwandlung von Anfragen und Antworten.

Mehr brauchen wir eigentlich nicht, und auch, wenn das keine wirklich kurze Liste ist, die Verwendung der einzelnen Klassen ist nicht besonders kritisch. Beginnen wir mit dem schwersten, dem Codec.

Wenn wir diesen auf Basis von XmlCodec aufbauen, haben wir die Hälfte schon geschafft:  die Antworten (Response) werden automatisch in einen Accessor für XML umgewandelt und können anschließend anhand der Regeln, die wir noch definieren werden, durchlaufen werden. Was wir noch machen müssen, ist, die Daten, die gesendet werden sollen (Request), vorzubereiten. LastFM erwartet die einzelnen Parameter als Query-String von Name-Wert-Paaren, also z.B.:

method=artist.getEvents&artist=Cher&api_key=b25b959554ed76058ac220b7b2e0a026

Der API-Key wird immer angehängt, bei Anfragen, die Daten verändern, sogar noch eine Session und ein API-Secret, diese lassen wir jedoch hier unter den Tisch fallen. Man muss es ja nicht gleich übertreiben. Unser Last.FM Codec könnte also folgendermaßen aussehen:

 public class LastFMCodec : XmlCodec
 {
   private string apiKey;

   public LastFMCodec(string key)
     : base("lfm", null)
   {
     this.apiKey = key;
   }

   public override Request Encode(Method m, Parameters p)
   {
     string method = m.Name;
     string query = "method=" + method + "&";
     query += p.QueryString("&", "=");
     query += "api_key=" + this.apiKey + "&";
     if (m.IsPOST) return new Request("", query);
     else return new Request(query, "");
   }
 }

Das wars auch schon. Das meiste wird ohnehin von SharpConnect erledigt, sodass wir uns nun auf den Apitizer konzentrieren können. Auch hier ist die Klasse XmlApitizer eine wunderbare Grundlage, die nicht viele Ergänzungen benötigt:

 public class LastFMApitizer : XmlApitizer
 {
   public LastFMApitizer(string key, WebProxy p)
     : base("http://ws.audioscrobbler.com/2.0/", new LastFMCodec(key), p)
   {
      AddMethods(this);
   }

   private static void AddMethods(XmlApitizer api) {
     // Methods here!
   }
 }

Wir haben nun also einen Apitizer erstellt, der alle Anfragen an “http://ws.audioscrobbler.com/2.0/” sendet und den soeben definierten Codec verwendet. Nun müssen wir dem Apitizer nur noch sagen, was er eigentlich kann.

Eine Methode wird definiert durch

• einen Namen,
• eine Liste von Parameter-Namen,
• eine Liste von boolschen Werten, die angibt, welche Parameter benötigt werden, sowie
• einen Wert der angibt, ob die Anfrage über HTTP-POST läuft oder nicht.

In unserem Fall sieht dies nun folgendermaßen aus (Der API-Key wird im Encoder automatisch hinzugefügt!):

 Method artistGetEvents = new Method(
   "artist.getEvents",
   new String[] { "artist" },
   new bool[] { true },
   false
 );

Was machen wir nun mit der Antwort dieses Aufrufs? Die Antwort: wir verwenden die Klasse XmlRule, um Zuordnungen zwischen Attributnamen und Knoten des Antwortdokuments herzustellen. Das Mittel der Wahl ist hierbei XPath.

 XmlRule Image = new XmlRule();
 Image.Set("URL", "self::node()");
 Image.Set("Size", "@size");

 XmlRule Event = new XmlRule();
 Event.Set("Name", "title");
 Event.Set("ID", "id");
 Event.Set("Artists", "artists/artist");
 Event.Set("Headliner", "artists/headliner");
 Event.Set("Date", "startDate");
 Event.Set("Time", "startTime");
 Event.Set("Description", "description");
 Event.Set("Images", "image", Image);             // !!!
 Event.Set("Attendance", "attendance");
 Event.Set("ReviewCount", "reviews");
 Event.Set("UniqueTag", "tag");
 Event.Set("Website", "website");

 XmlRule rule = new XmlRule();
 rule.Set("Count", "/lfm/events/@total");
 rule.Set("Events", "/lfm/events/event", Event); // !!!

Zuerst wird eine Bild-Regel definiert: das Attribut “URL” liefert den Wert des Knotens, “Size” den Wert des “size”-Attributs. Die beiden blauen Zeilen zeigen die Verwendung von bestehenden Regeln als Unterobjekte: die Regel “Image” ist auf alle Knoten anwendbar, die über das Attribut “Images” gefunden werden, d.h. jeder Knoten aus “Images” erlaubt wieder Zugriff auf “URL” und “Size”. Gleiches für “Events”: alle Knoten, die über den XPath-Ausdruck “/lfm/events/event” gefunden werden, haben Attribute “Name”, “ID”, “Artists”, …

Wir müssen nur noch dem Decoder sagen, dass er diese Regel verwenden soll, wenn er eine Antwort auf eine “artist.getEvents”-Anfrage erhält. Dies geschieht durch gleichzeitiges Registrieren der Methode im Apitizer und Codec mittels “Apitizer.Method” (Wir befinden uns wieder in der statischen Funktion “AddMethods” von oben):

api.Method(artistGetEvents, rule);

Und nun sind wir fertig.

Beispiel gefällig?

Das folgende Beispiel funktioniert mit meiner aktuellen Implementierung von SharpConnect. Neu im Vergleich zum eben besprochenen ist nur die Klasse “LastFMValue”, die den Accessor für XML-Dokumente darstellt:

 LastFMApitizer lfm = new LastFMApitizer("b25b959554ed76058ac220b7b2e0a026", "", null);

 LastFMValue resp = lfm.Execute("artist.getEvents", new Parameters(
   "artist", "Kasabian"
 ));
 if (resp != null)
 {
   Console.Write(resp.ToString()); // oder z.B. Console.Write(resp.All("Events")[2].Value("Date"));
 }
 Console.ReadLine();

Die Ausgabe sieht so oder  ähnlich aus (auf all diese Attribute und Array-Elemente könnte man mittels “resp.Get(attribut)”  und “resp.All(attribut)” zugreifen, vgl. den Concept-Artikel):

  Status : ok
  Count : 14
  Events[0] :
    Status : ok
    Name : Kasabian
    ID : 1408186
    URL : http://www.last.fm/event/1408186+Kasabian+at+Tivoli+Oudegracht+on+27+May+2010
    Artists : Kasabian
    Headliner : Kasabian
    Date : Thu, 27 May 2010 12:08:01
    Description : ...
    Images[0] :
      URL : http://userserve-ak.last.fm/serve/34/284053.jpg
      Size : small
    Images[1] :
      URL : http://userserve-ak.last.fm/serve/64/284053.jpg
      Size : medium
    Images[2] :
      URL : http://userserve-ak.last.fm/serve/126/284053.jpg
      Size : large
    Images[3] :
      URL : http://userserve-ak.last.fm/serve/252/284053.jpg
      Size : extralarge
    Attendance : 87
    ReviewCount : 0
    UniqueTag : lastfm:event=1408186
    Website : http://www.tivoli.nl/agenda/informatie/datum/do-27-mei-2010/titel/KASABIAN
  Events[1] :
    Status : ok
    Name : Pinkpop 2010
    ID : 932823
    URL : http://www.last.fm/event/932823+Pinkpop+2010
    Artists[0] : Green Day
    Artists[1] : Pixies
    Artists[2] : Kasabian
    Artists[3] : The Prodigy
    Artists[4] : Rammstein
    Artists[5] : John Mayer
    Artists[6] : Editors
    Artists[7] : Mika
    Artists[8] : Wolfmother
    Artists[9] : Kate Nash
    Artists[10] : Mando Diao
    Artists[11] : Paolo Nutini
    Artists[12] : P!nk
    Artists[13] : Florence + The Machine
    Artists[14] : Skunk Anansie
    Artists[15] : Gogol Bordello
    Artists[16] : Biffy Clyro
    Artists[17] : Yeasayer
    Artists[18] : The Temper Trap
    Artists[19] : Danko Jones
    Artists[20] : Gossip
    Artists[21] : 2 Many DJ's
    Artists[22] : Moke
    Artists[23] : Kitty, Daisy & Lewis
    Artists[24] : Caro Emerald
    Artists[25] : Triggerfinger
    Artists[26] : Destine
    Artists[27] : DeWolff
    Artists[28] : Sungrazer
    Headliner : Green Day
    Date : Fri, 28 May 2010 21:24:01
    Description : ...
    Images[0] :
      URL : http://userserve-ak.last.fm/serve/34/42600061.jpg
      Size : small
    Images[1] :
      URL : http://userserve-ak.last.fm/serve/64/42600061.jpg
      Size : medium
    Images[2] :
      URL : http://userserve-ak.last.fm/serve/126/42600061.jpg
      Size : large
    Images[3] :
      URL : http://userserve-ak.last.fm/serve/252/42600061.jpg
      Size : extralarge
    Attendance : 560
    ReviewCount : 1
    UniqueTag : lastfm:event=932823
    Website : http://www.pinkpop.nl
  Events[2] :
    Status : ok
    Name : Kasabian
  ...

Ich arbeite im Moment an einer vollständigen Abbildung des Last.FM-APIs, auch wenn ich nicht weiß, ob ich das nicht lieber jedem selbst überlassen sollte. In den Worten von Morpheus:

I can only show you the door, you have to walk through it!

Und heute war ich dann soweit, dass ich eine gar nicht so üble Version vor mir hatte, die ich nun (nicht detailliert, eher angeberischerweise ) präsentieren will. Vorhang auf für Scripe!

(Der Name hat mehrere Hintergründe: zum einen wäre da der Schreibfehler, der schonmal beim Wort “Scripte” auftaucht, zum anderen findet sich ein Ursprung im englischen “to scribe”, was soviel wie “vorzeichnen” bedeutet. Zuguterletzt sagt einem das allwissende Urban Dictionary, das “scripe” das Äquivalent von “a load of rubbish”, also etwas nicht ganz hochwertigem ist. Das ist auch in Ordnung so: Scripe ist der Weg, den ich einschlagen würde, wenn ich eine Scriptsprache zu entwickeln hätte. Zwar sind Grundkonzepte, die sich auch im professionelleren Einsatz finden, vorhanden, aber Scripe erhebt in dieser Hinsicht keinerlei Anspruch auf Vollständigkeit oder übermäßige Effizienz. “Quick and Dirty” wäre dennoch übertrieben, dann doch eher “Quick and Not-So-Clean“…)

Die Suppe im Titel lässt das Prinzip erahnen: Suppen brauchen Gewürze, um zu schmecken, und hierbei ist es wichtig auf die Mischung zu achten. Ebenso wird jeder seine Suppe anders würzen, je nach Vorlieben oder Vorhaben. Eine Scriptsprache ist da nicht anders: hier eine Prise Variablenverwaltung, dort ein Löffel Arithmetik. Voilà.

Dieses Suppenprinzip findet man heutzutage überall, hauptsächlich in der Unix/Linux-Welt, wo man je nach Bedarf auf einfachste Art und Weise ein Paket nachladen kann und das Gesamtsystem somit bis ins letzte Eck modifizierbar bleibt. Auch Scripe verwendet solche Pakete, allerdings eben für die Features der Programmiersprache!

Folgender C#-Code erzeugt einen Prozessor, der den Shunting-Yard-Algorithmus verwendet, um die Eingabe zu parsen. Anschließend erhält er vier Pakete: eines für arithmetische Operationen, eines für String-Operationen, eines für Ein- und Ausgabe, und eines für Variablendefinition und -verwaltung. Anschließend wird eine Eingabe-Auswertungs-Schleife gestartet.

// Create processor
Processor p = new Processor(
    new ShuntingYardAlgorithm()
);

// Add packages
p.AddPackage(new Scripe.Evaluators.Arithmetic.ArithmeticPackage(true));
p.AddPackage(new Scripe.Evaluators.Strings.StringPackage("&", "$"));
p.AddPackage(new Lapicon.Evaluators.InputOutput.InputOutputPackage());
p.AddPackage(new Lapicon.Evaluators.Variables.VariablePackage());

// Empty codebase
Codebase c = new Codebase(new Scripe.Env.Environment());

// Read-Eval-Print-Loop
string r = "";
while (true)
{
    try
    {
        Console.Write("Calc: ");
        if ((r = Console.ReadLine()) == "exit") break;
        c.Add(r);
        Console.WriteLine(" ==> " + c.Execute(p).ReturnValue);
    }
    catch (Exception ex)
    {
        Console.WriteLine(" ERROR: " + ex.Message);
    }
}

In nur 5 Zeilen haben wir hier (mithilfe der Scripe-internen und zweier für Lapicon geschriebenen Pakete) einen Prozessor geschaffen, der jede der folgenden Eingaben auswerten kann:

1+(4-6)*(3-4^5)+e
def variable = 7*8
def variableDurchZwei = <variable>/2
echo "(7*8)/2 = " & $(<variableDurchZwei>)

Und nun stelle man sich eine Internetseite vor, die eine gewisse Anzahl solcher Pakete anbietet. Scriptsprachen entwickeln einfach gemacht.

Soviel also von mir. Wann Scripe letztlich ganz fertig ist (und ich mich wieder den anderen Projekten wie LastSharp widmen kann), kann ich nur schätzen. Ist ein Monat in Ordnung?

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
   

Da im Moment anscheinend wieder Änderungen am Last.FM-Webservice gemacht werden, die dazu geführt haben, dass LastSharp höchstens noch mithilfe der “Modifizierten Verbindung” (unter “Erweiterte Einstellungen” >> “Verschiedenes”) funktioniert, habe ich mir mal das Radio-API angesehen, das ja anscheinend die Zukunft des Radiostreamings bei Last.FM ist. Was mich daran allerdings stört, ist die umständliche Anmeldeprozedur: Token holen, Browser öffnen, auf Authentifizierung warten, Session holen.

Der Umweg über den Browser ist einfach unschön, weshalb ich nach einer Lösung gesucht habe, die den Login sowie die anschließende Bestätigung eines Users im Hintergrund simuliert, sodass er das eigentliche Programm nicht verlassen muss.

Funktionen, die Authentication-Token und -Session holen, werden im folgenden als gegeben betrachetet, z.B. durch LastFmLib.Net.

Wir brauchen nun also zwei Funktionen, die das Abschicken des Login-Formulars und das Klicken auf den “Zulassen”-Button vortäuschen. Beide Operationen produzieren eine HTTP-POST-Anfrage, funktionieren aber nur, wenn auch die richtigen Cookies vorhanden sind. (Das hat mich einige Zeit gekostet und dabei war die Lösung so einfach…) Es bietet sich an, die POST-Anfrage in eine Hilfsfunktion ExecutePOST zu packen, hier z.B. in C#:
(Namespace System.Net muss eingebunden sein)

// Löst das Cookie Problem: Immer denselben Container verwenden!
private static CookieContainer GlobalCookies = new CookieContainer();

// Sendet eine POST-Anfrage
public static void ExecutePOST(string uri, string data) {
    try
    {
        // Bereite die Anfrage vor
        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
        request.Method = "POST";
        request.CookieContainer = GlobalCookies; // !!
        request.ContentType = "application/x-www-form-urlencoded";
        request.ContentLength = data.Length;

        // Schreiben der Daten
        ASCIIEncoding enc = new ASCIIEncoding();
        byte[] bdata = enc.GetBytes(bodyData);
        Stream str = req.GetRequestStream();
        str.Write(bdata, 0, bdata.Length);
        str.Close();

        // Schicke Anfrage ab und verwirf die Antwort
        HttpWebResponse response = (HttpWebResponse)request.GetResponse();
        response.Close();
    }
    catch { }
}

Will man überprüfen, ob die gewünschte Operation erfolgreich war, würde es sich vermutlich anbieten, die Antwort auszuwerten, aber darauf verzichte ich jetzt aus Zeitgründen.

Nächster Schritt ist die Untersuchung der Formulare auf der Last.FM-Seite, damit man weiß, welche Daten an welche Adresse gesendet werden müssen:

• Login: https://www.last.fm/login/
  • refererKey (leer)
  • backto (“/”)
  • username (Benutzername)
  • password (Passwort)
• Zulassen: http://www.last.fm/api/grantAccess
  • api_key (Last.FM schickt den sogar zweimal, wir deshalb sicherheitshalber auch…)
  • token (Authentication-Token)
  • referer (“/”)

Also, die beiden verbleibenden Funktionen in C#:

    // Lasse ein Programm zu
    public static void GrantAccess(string token)
    {
        ExecutePOST(
            "http://www.last.fm/api/grantAccess",
            "api_key=" + apiKey + "&api_key=" + apiKey + "&token=" + token + "&referer=/"
        );
    }

    // Melde den User bei Last.FM an
    public static void Login(string username, string password)
    {
        ExecutePOST(
            "https://www.last.fm/login/",
            "refererKey=&backto=/&username=" + Uri.EscapeDataString(username) +
            "&password=" + Uri.EscapeDataString(password)
        );
    }

Um jetzt eine gesamte Anmeldung zu simulieren, müsste man nun folgendes machen:

public static void Authenticate(string username, string password)
{
    string token = GetToken(); // irgendeine externe Funktion
    Login(username, password);
    GrantAccess(token);
    string session = GetSession(); // irgendeine externe Funktion
    // Mache etwas...
}

Das war’s auch schon. Wie gesagt fehlt hier ein Test, ob die Anmeldung erfolgreich war, aber irgendwie lässt sich das bestimmt einfach überprüfen. (Vllt. liefert Last.FM ja im Hintergrund einen HTTP-Error, der im Browser nicht auffällt?)

Jedenfalls, wenn jemand die Authentifizierung für das Last.FM-API 2.0 im Hintergrund ablaufen lassen will, ist das hier der Weg. Ich hoffe, es hilft.

Die Verwendung des Radio-APIs in LastSharp werde ich übrigens so lang wie möglich hinauszögern, da hier wieder einmal diverse Standards (HTTP, XML, …) unsachgemäß ausgelegt werden…

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.