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!

Mein Problem begann beim Last.FM-Webservice: wie kann ich dessen Funktion möglichst einfach zugänglich machen, ohne Flexibilität zu verlieren? Ich wollte nicht auf eine bereits bestehende Lösung zurückgreifen, da dort womöglich viel mehr angeboten als letztendlich benötigt wird; genauso sollte keine neue, nur für Last.FM nutzbare Implementierung geschaffen werden, sei sie auch noch so einfach zu verwenden – irgendwann müsste dann doch wieder von vorne begonnen werden… Eine neue Abstraktionsschicht musste her, eine vereinfachte, für den Otto-Normal-Programmierer sinnvolle Minimal-Version von WSDL quasi. Etwas, das leicht zu erlernen und zu verwenden ist, ohne unnötigen Ballast.

Methoden

Im Prinzip kann man jede Funktion eines WebServices als Methode beschreiben. Diese hat:

• einen Namen,
• eine Reihe von Parametern,
• Informationen zu diesen Parametern (Typ? Optionaler Parameter?),
• sowie ein Zugriffsprotokoll
• und ein Antwortformat.

Je genauer man Methoden beschreibt, desto sicherer kann man sich sein, dass ein Aufruf, der alle Anforderungen erfüllt, auch wirklich erfolgreich ist. Nur: die Daten, die so fällig werden, nehmen schnell an Größe und Komplexität zu, sodass man eigentlich nicht umhin kann, das Messer anzusetzen und so viel wie möglich wegzuschneiden:

• Zugriffsprotokoll:
  So ziemlich alle wichtigen WebServices sind über HTTP ansprechbar. Es ist nicht verwerflich, sich hierauf zu begrenzen.
• Parametertypen:
  Letztlich erfolgt an irgendeiner Stelle immer eine Umwandlung in Strings, vor allem bei textbasierten Protokollen wie HTTP. Ersparen wir uns also die statische Typisierung, die ohnehin schwer zu implementieren ist.
• Antwortformat:
  Auch hier könnte man sagen, dass man an XML ohnehin nicht vorbeikommt, allerdings ist in diesem Bereich Flexibilität wichtig: neue Formate wie JSON sind auf dem Vormarsch, vor allem für einfachere Anwendungen. Einigen wir uns darauf: Die Methode muss nicht wissen, wie ihre Antwort aussieht!

Übrig bleibt das in folgender Schreibweise zusammengefasste bisschen Information:

Methode   M  = (Name, HTTP-Methode, [Parameter P1, Parameter P2, ...])
Parameter Px = (Name, required?)

Als Beispiel sei der Aufruf artist.getInfo des Last.FM-APIs notiert:

Methode M1   = (artist.getInfo, GET, (artist, false), (mbid, false), (username, false), (lang, false))

Diese Methode ist bewusst gewählt: die Spezifikation besagt, dass sie entweder mit einem Künstlernamen (artist) oder einer Musicbrainz-ID aufgerufen werden kann. Dies haben wir hier nicht abgebildet, können wir aber gut und gerne dem Nutzer überlassen oder eben nachholen, indem wir zwei verschiedene Methoden definieren:

Methode M1   = (artist.getInfo, GET, (artist, true), (username, false), (lang, false))
Methode M2   = (artist.getInfo, GET, (mbid, true), (username, false), (lang, false))

Wir können jede Operation, die ein WebService bietet, so aufschreiben – und viel wichtiger: wir können dies in jeder objektorientierten Sprache sehr einfach implementieren. Ein paar Konventionen zur Schreibweise sind jedoch noch nötig:

• Methodenaufruf:

  Aufruf A = M(P1 -> V1, P2 -> V2, ...)

  Der Parameter P1 wird mit V1 belegt, usw… z.B. für artist.getInfo (s.o.):

  Aufruf A1 = M1(artist -> Kasabian, username -> xschemer, lang -> de)

  Die Reihenfolge der Parameter ist unerheblich.

• Methodenaufruf ohne Parameterzuordnung:

  Aufruf A = M(V1, V2, V3, ...)

  V entspricht dem ersten in der Definition angegebenen Parameter, usw… Semantisch identisch zum obigen Beispiel:

  Aufruf M1(Kasabian, xschemer, de)

Die Definition eines APIs haben wir erledigt, den Methodenaufruf spezifiziert. Aber was machen wir nun damit?

Request, Response & Codec

Ein WebService kann mit einer Methode erst etwas anfangen, wenn sie in dem Format aufgerufen wird, dass er versteht. Für Last.FM muss z.B. immer ein “method”-Parameter übergeben werden, der den Namen enthält, zusätzlich noch der API-Key, evtl. eine Session und eine Signatur.

Damit wir einen Aufruf in das richtige Format bringen können, brauchen wir einen sog. Codec, also einen Umwandler. Er nimmt einen Methodenaufruf und produziert daraus die URL, an die eine Anfrage geschickt wird, sowie die Daten, die gesendet werden. Ebenso verarbeitet er die Antwort des Servers zu einem standardisierten Objekt (Accessor), das weiter unten beschrieben ist. Im Prinzip handelt es sich also nur um zwei separate Funktionen, konkretisiert:

Request  Rq = (URL, Daten)
Response Rp = (Request, Daten)
Codec    C  = (Encoder, Decoder)
Encoder  E  = Funktion: Aufruf -> Request
Decoder  D  = Funktion: Response -> Accessor

Wenn wir hier aufhören, haben wir folgenden Datenfluss:

User -> Codec -> Encoder -> WebService -> Decoder -> Codec -> User

Was uns immer noch fehlt ist eine Überprüfung, ob zumindest alle benötigten Parameter vorhanden sind. Zwar könnte man diese in den Encoder packen, doch das sollte nicht dessen Aufgabe sein, schließlich müsste er dafür alle Methoden kennen, was schlicht und einfach keinen Sinn macht.

Apitizer – Wächter der Methoden

Diese Verwaltung wird also in ein neues Objekt verlagert, den Apitizer. Er übernimmt die folgenden Aufgaben:

• Speicherung aller verfügbaren Methoden,
• Verwaltung genau eines Codecs,
• Auswahl der passenden Methode zu einem Name-Parameterliste-Paar,
• sowie Überprüfung von Parameterlisten auf Vollständigkeit.

Jede Kommunikation eines Users mit dem API sollte über den Apitizer laufen, nicht direkt über Encoder und Decoder! Das folgende Bild soll das nochmals verdeutlichen:

Was man hier auch sieht, ist die Möglichkeit, des Encoders/Decoders auf externe Daten zurückzugreifen, z.B. den API-Key bei Last.FM. Aber nun erstmal zum wohl wichtigsten Teil dieses Konzepts, den Accessor.

Accessor

Wenn wir eine Antwort bekommen, interessieren uns bestimmte Teile davon. Allerdings existieren unterschiedliche Formate, unterschiedliche Strukturen. Es gilt also, diese auf ein einfaches Konzept zurückzuführen.

Betrachten wir die grundsätzlichen Arten von Daten, die es gibt:

• einzelne Werte,
• Mengen von Werten,
• Zusammengesetzte Strukturen,
• sowie Mengen von zusammengesetzten Strukturen.

Definieren wir diese folgendermaßen:

Wert    V  = String | List | Struct
List    L  = (Wert, Wert, ...)
Struct  S  = (Mapping, Mapping, ...)
Mapping Mp = String -> Wert

In Worten: ein Wert ist entweder ein String, eine Liste oder eine Struktur; eine Liste ist eine Menge von Werten und eine Struktur ist eine Menge von Zuordnungen von Strings zu Werten. Letzteres entspricht den Attributen eines Objekts. (z.B. kann die Struktur “Rechteck” eine Zuordnung “Höhe” -> “10″ besitzen)

Ein Accessor bildet nun beliebige Daten mithilfe von Regeln auf die eben besprochenen Einheiten ab:

Regel          Rl = (AccessMapping1, AccessMapping2, ...)
AccessMapping  AM = (Attributname, Transformation, Regel)
Transformation T  = Funktion: Daten -> Daten[]
Accessor       Ac = (Daten, Regel)

Der Accessor muss in der Lage sein, die folgenden Operationen auszuführen:

• das passende Mapping zu einem Attributnamen finden,
• den aktuellen Daten-Wert als String ausgeben,
• einen Accessor erstellen, der einem Attribut entspricht,
• eine Menge von Accessors erstellen, die einer Menge von Attribut-Werten entspricht.

Und wieder wird definiert (das ist keine besondere Beschreibungssprache, nur Pseudo-Code):

Accessor.map(attribut)  -> AccessMapping
Accessor.value()        -> (String) Accessor.Daten
Accessor.get(attribut)  -> Accessor.all().firstElement
Accessor.all(attribut)  ->
    m = Accessor.map(attribut);
    d = m.Transformation(Accessor.Daten);
    Array for all d[n]: new Accessor(d[n], m.Regel)

Es wird Zeit für ein Beispiel. Und da XML mein Hauptanliegen ist, sollte ich es wohl auch verwenden.

Beispiel: XML Accessor

Auf XML-Daten kann mithilfe von XPath zugegriffen werden und dies kann man wunderbar nutzen. Nehmen wir das folgende Dokument:

<fruitbasket>
  <count>2</count>
  <fruit>
    <name>Apple</name>
    <color>red</color>
  </fruit>
  <fruit>
    <name>Orange</name>
    <color>orange</color>
  </fruit>
</fruitbasket>

Wir können nun Regeln definieren, wobei wir davon ausgehen, dass Transformationen eindeutig durch einen XPath-Ausdruck bestimmt sind und auf dem Wurzelknoten des übergebenen Dokuments arbeiten, z.B. lässt sich auf die Anzahl der Früchte ausgehend vom Wurzelnoten “fruitbasket” mittels “count” zugreifen:

Regel Fruitbasket = (
  ("Count", xpath: "count", None),
  ("Fruits", xpath: "fruit", Fruit)
)

Regel Fruit = (
  ("Name", xpath: "name", None),
  ("Color", xpath: "color", None)
)

Diese Regeln müssen irgendwo im Decoder definiert sein, ebenso eine Zuordnung Methodenname -> Regel, damit der Decoder weiß, für welche Methode er welche Regel verwenden soll. Ein Accessor, der das oben beschriebene Dokument (abgekürzt als FRUITDOC) repräsentiert wäre also:

Accessor MyBasket = (FRUITDOC, Fruitbasket)

Wenn man nun die Methode “all” für das Attribut “Fruits” aufruft, wird der Accessor feststellen, dass dies dem AccessMapping (“Fruits”, xpath: “fruit”, Fruit) entspricht. Er wendet also die Transformation auf das Dokument an (findet also alle Knoten, die dem XPath-Ausdruck “fruit” entsprechen) und erstellt mithilfe der gegebenen Regel Fruit neue Accessors. Das Ergebnis wäre also:

MyBasket.all("Fruits") = [
  Accessor("<fruit><name>Apple</name>...", Fruit),
  Accessor("<fruit><name>Orange</name>...", Fruit)
]

Führen wir nun “get” für das Attribut “Color” des ersten Ergebnisses (nennen wir es E1) aus, erhalten wir das AccessMapping (“Color”, xpath: “color”, None). Eine Auswertung des XPath-Ausdrucks liefert hier genau einen Knoten, aus dem der neue Accessor V1 erstellt wird:

V1 = E1.get("Color") = Accessor("<color>red</color>", None)

Und hier können wir den Wert auslesen:

V1.value() = "red"

Das gleiche Ergebnis würde übrigens der folgende Ausdruck liefern:

MyBasket.get("Fruits").get("Color").value()

Soviel zu Accessors.

Warum? Warum? Warum?!

Wie anfangs (und das ist lange her) erwähnt, arbeite ich an meiner Version des Last.FM-APIs auf Basis dieses Konzepts. Dieses wiederum wird die Basis für neue Versionen von LastSharp und LeSharp sein, wobei ich v.a. für ersteres Programm grundlegende Änderungen angedacht habe. (Multiuser-Support mit mehreren Downloads, Anhören und Downloaden gleichzeitig, …)

Es hat also schon alles seinen Sinn. Danke fürs Zuhören.

Attributname : String, Transformation, Unterregel

Eine kleine Analyse brachte das Problem zutage: der installierte Apache 2 Server fraß die Resourcen auf, anscheinend beim Versuch, sich mit der MySQL-Datenbank (die ich zwecks einfacher Weiterbetreibung dieses Blogs behalten habe) zu verbinden. Und egal, wo ich an der Konfiguration herumgeschraubt habe, es hat nichts gebracht.

Also bin ich einen anderen Weg gegangen: ein neuer Webserver musste her. Und hierbei fiel mein Auge auf nginx (Engine X). (Homepage) Eine kurze Installation und eine unglaublich einfach zu erledigende Konfiguration später, lief er dann auch schon. Und siehe da: keine Abstürze, keine langen Wartezeiten. Einfach Wow!

Jetzt muss ich nur noch cakePHP zum Laufen bekommen, dann wäre die Welt perfekt… Läuft.

Oh, noch nebenbei die Konfiguration für diesen Wordpress-Blog, falls jemand auf der Suche nach den Rewrite-Rules sein sollte (nginx unterstützt keine .htaccess Dateien):

server {
	listen 80;
	server_name dev.xscheme.de;

	location / {
		root [...];
		index index.php;
		if (!-e $request_filename) {
			rewrite ^ /index.php last;
		}
	}
	...
}

Wo genau ich das gefunden habe, weiß ich jetzt auch nicht mehr…

Aber jetzt sollte wieder alles funktionieren. Wenn nicht, bitte bescheid sagen!

Update: Um das Forum kümmere ich mich morgen.

Download:
https://sourceforge.net/projects/lastsharp/files/lesharp/LeSharp%201.2.2/LeSharp1.2.2.zip/download

Zum einen bin ich letzten Samstag umgezogen (der klassische Studentenweg: von Zuhause weg und in eine 2er-WG) und da jetzt dann doch ziemlich eingebunden. Ich hab noch nichtmal ein Bett… (Lieferzeit: 3 Wochen)

Seit September arbeite ich zudem als Werkstudent bei Telefonica O₂ Germany. Die 20h-Woche ist jetzt vielleicht nicht sooo auslastend, aber es summiert sich dann doch.

Zuguterletzt geht dann demnächst auch die Uni wieder los, was mein Pensum dann auf 50h die Woche erhöht. Aber mei, wir sind jung – wenn wir jetzt sowas nicht packen, wann dann?

Jedenfalls werde ich alle offenen Kommentare beantworten, sobald ich Zeit habe. Ebenso wird es dann neue Versionen der einzelnen Programme geben. Danke für’s Verständnis!

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