[linux-l] Grammar Design

[Oliver Bandel]

Moin, Volker,


On Fri, Sep 16, 2005 at 05:48:03PM +0200, Volker Grabsch wrote:
> On Fri, Sep 16, 2005 at 03:01:10PM +0200, Oliver Bandel wrote:
> > On Sat, Jul 09, 2005 at 01:49:33AM +0200, Oliver Bandel wrote:
> > > Also: Wie entwirft man auf elegante und effiziente/schnelle Weise
> > >      eine Grammatik, ohne sich all zu oft in Parser-Konflikten
> > >      zu verlieren.
> > 
> > Nach Auskunft einiger Leute mit Peilung gibt's da oftmals nur eins:
> > so weit wie möglich sich klar werden, was man implementieren will,
> > am besten sich mal ne Beispielsyntax anfertigen und dann loslegen.
> > ggf. mehrfaches redesign bzw. neues Konzept.
> 
> Dem kann ich mir nur anschließen. Übrigens hatten wir an der Uni zwar
> "Compilerbau", dort war allerdings unsere Sprache schon detailliert
> vorgegeben.
> 
> > Naja, also habe ich mal etwas herum experimentiert mit einem
> > Progrämmchen, das pdf's generiert (speziell für Tanzbereich/Bewegungsanalyse).
> 
> Ich habe, abgesehen von dem Compiler für die Uni, auch noch einen
> Interpreter für eine eigene Sprache geschrieben, die speziell für
> IRC-Bots gedacht ist:
> 	http://davis.sf.net/
> 
> Allerdings habe ich dort alles "per Hand" gemacht. Das war noch zu
> Schulzeiten.
> 
> Momentan stehe ich wieder kurz vor einem Projekt, wo ich das brauche:
> 	http://wikidok.njh6.de/

Werde ich mal nen Blick rein werfen.


> 
> Gerade wegen dem vielen Ausprobieren und Redesign sind mir lex/yacc
> einfach zu aufwändig. Deshalb habe ich mich vorerst für "pyparser"
> entschieden. Das ist eine Python-Bibliothek, mit der man Grammatiken
> nochmals sehr viel einfacher beschreiben kann. Ich wende also
> "Rapid Prototyping" an.

Naja, ich nutze ocamlley/ocamlyacc, das ist schon wegen Ocaml
rapid prototyping.
Bei Ocaml gibt es auch andere Parser-Mechanismen, z.B.
Stream-Parser via camlp4.

Aber gerade wegen der Kompatibilität zur C-Welt habe ich mich
dann für ocamllex/ocamlyacc entschieden.
Falls daraus doch mal was kommerzielles wird, und OCaml
aus dem einen oder anderen Grunde ausscheiden sollte,
muß ich wenigstens das lex/yacc-Zeugs nicht nochmal komplett
neu machen.


> Auch der Rest des Programmes ist in Python
> erstmal besser aufgehoben als in C.

Ja, ist anzunehmen.


> Wenn alles läuft, kann ich mir
> immer noch überlegen, ob die Sache nochmals mittels lex/yacc neu
> zu implementieren,

Na, das ist dann aber sehr auwändig, denn nicht nur der
Drumherum-Code muß neu gemacht werden, sondern dann geht es
los mit dem lex/yacc-Zeugs...das auch nochmal neu zu machen.
Und das kann ja manchmal etwas nervig sein- obwohl, mit genug
Übung geht das wohl.

(Aber die Sache mit Parse-Errors nervt: man kriegt da manchmal
etwas seltsame Zeilennummern als Ergebnis... aber das liegt wohl
am Parser-Vorgehen. Müsste man ansonsten doch krassere Parser einsetzen.


> aber meistens ist dieser Schritt gar nicht nötig,
> weil Python schon genug Performance liefert.

Für die meisten Sachen denke ich, ist sowas unkritisch.


> 
> Doch selbst wenn feststeht, dass du es in C machen willst,

Halte mir das offen, falls das notwendig ist.
Wenn das Umfeld zu solchen Vorgaben zwingen sollte...


> rate ich
> dennoch an, gerade diese Ausprobieren/Verwerfen - Phase mit besseren,
> einfacheren Tools zu beschreiten (z.B. mit pyparser). Danach die Sache
> nach lex/yacc zu bringen (besser gesagt: flex/bison), ist mehr oder
> weniger trivial, also IMHO das kleinere Übel.

Naja, da ist man dann so verwöhnt, daß man nen Hals kriegt,
wenn man von den guten Tools wieder zurück soll.


Ich würde C nur noch nehmen, wenn das erforderlich ist
aufgrund von Vorgaben.

Ansonsten wäre das ja Masochismus. ;-)

Bloß wenn dann doch C sein soll, dann steht wenigstens schon
das Gerüst von lex/yacc - bis auf einige Änderungen halt,
die in der C-Version nicht so schön sind.

Ciao,
   Oliver