Parser mit Ragel

komplizierte Grammatiken und rattenschnelles XML

Vortrag am 22. September 2010

If you graph these numbers, patterns emerge. Max Cohen, PI

Warum Parser bauen?

trotz XML, JSON, YAML etc.:

eigene maßgeschneiderte Protokolle,
3rd Party Libs nicht vorhanden,
nicht gut genug oder
Lizenzprobleme.

Was spricht gegen Ad-Hoc Parsing (a.k.a. Gefrickel)?

der Parser sollte korrekt sein,
Wartbarkeit,
BNF Grammatik ist meist schon da,
fast immer schlechter als ein humorloser Zustandsautomat.

Quelltext Impression

z.B. die XML Spec sagt:

document    ::= prolog element Misc*
prolog      ::= XMLDecl? Misc* (doctypedecl Misc*)?
XMLDecl     ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
VersionInfo ::= S 'version' Eq ("'" VersionNum "'" | '"' VersionNum '"')

Ragel will:

VersionInfo   = S 'version' Eq ("'" VersionNum "'" | '"' VersionNum '"');
XMLDecl	      = '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>';
prolog        = XMLDecl? Misc*;
document      = prolog elem_query Misc*;

und natürlich noch ein paar Zaubersprüche rundrum.

Wie komme ich drauf?

Experiment ob SVG (Path Syntax!) als Speicherformat für piccolo2d.org, eine Java 2D Scenegraph API taugt. Dann könnten Designer die Screens direkt mit Illustrator oder Inkscape bauen. Ergebnis: evtl.,
iPhone App soll ca. 500K einfaches XML schneller als NSXMLParser parsen (14 Sec.). Ergebnis: 0.3 Sec.

Anschnallen: Die Bausteine

die Grammatik (BNF-artig)
„Actions“ bzw. Callbacks in die eigene Logik
Treiber Code um das ganze loszutreten
ragel Kommandozeile per Makefile
- Zustandsautomat in C compilieren
- Zustandsautomat via Graphviz visualisieren