[linux-l] Grammar Design

[Oliver Bandel]

Hi,


On Mon, Jul 11, 2005 at 12:03:10AM +0200, Ihno Krumreich wrote:
> hi,
> 
> habe schon den einen oder anderen Parser geschrieben (mit
> lex&yacc, aber auch nur in C).

Naja, lex&yacc. Ich mache das möglicherweise in C, aber
solange es für C keine Notwendigkeit gibt (z.B. kommerzielles
Umfeld), nehme ich ocamllex&ocamlyacc && OCaml. :)
Kommt man eben schneller zum Ziel.



> Bisher handelte es sich dabei um Konfigurationsdateien
> (eigen und fremddesign).

Bisher noch nicht. Vielleicht wird das mal notwendig.
Aber sowas würde ich vermutlich über einen Sprachinternen "loadconfig"-
Befehl oder so realisieren.

Naja, da ich das noch nicht so oft ;-) gemacht habe, daß ich eine eigene
Sprache entwickelt habe, weiß ich da auch erst mal noch nicht, was
das optimale sein wird.

> 
> Was fuer Eigenschaften soll den deine Sprache haben?

Es sollen ja mehrere Sprachen werden.

Aber ich habe gestern mal mit was angefangen, das mir das Gestalten
von komplizierten Layouts drastisch vereinfacht.
So eine Art Preprozessor zu Lout (oder später LaTeX oder direkt Postscript).


> 
> - Wird einmal ein Konfigurationsdatei eingelesen?

Bisher nicht geplant.


> - Soll ein "Programm" eingelesen werden, das hinterher interpretiert wird?

Das ist der Hauptschwerpunkt erst mal.


> - Oder sollen fortlaufend Daten eingelesen und verarbeitet werden?

Spätere Sprachen sollen auch das mal tun. Also entweder als Streamingfilter
oder wie man das nennen mag.


Erst mal soll ein Programm eingelesen und verarbeitet werden.


> 
> Ich habe es bisher immer so gemacht, das ich Funktionsbloecke
> definiert habe, die ich dann immer weiter verfeinert habe.

Funktionsblöcke.... hast Du das so angedacht, daß Du das mit einer
speziellen Syntax vorgibst, also daß Du mit einem Befehl pro
Funktionsblock sozusagen Sub-Grammatiken aufgebaut hast, und
dann später weitere hinzugefügt hast?

Wie sieht es mit Datentypen aus?
Sollte man das als erstes ansetzen (um die terminalen Symbole
schon mal für den lexer vorab festgelegt zu haben?).

Noch bevor man Funktionsblöcke zusammen baut?

Andererseits braucht eine bestimmte Funktionalität ja automatisch bestimmte
Typen von Daten (also Stringbasiert, oder auch Arithemtik oder so...).



> Parallel zur Sprache muss ja auch die Datenstruktur definiert
> werden. Damit man sich hinterher nicht selbst ein
> Bein stellt.
[...]


naja, die ersten Experimente für meinen "Lout-Preprozessor" bzw.
Layout-Generator sahen so aus, daß ich die Konvertierung gleich
in der yacc-Grammar erzeugt habe.

Aber spätestens (vermutlich schon viel früher), wenn ich auch nach LaTeX
konvertieren möchte, bzw. wenn ich einfach nur flexibel sein will,
brauche ich wohl ne eigene Datenstruktur, anstatt die Ergebnisse
nur von unten nach oben in der jew. yacc-Action nach oben zu reichen.

Das Teil kann mir derzeit die Befehle "above" "below" "rightof" "leftof"
ausführen, ich kann stringvariablen definieren, habe die Möglichkeit,
Definitionen bzw. Anordnungen der Textboxes mit Klammern zu Priorisieren...

Wenn ich zwei vordefinierte Layoutabschnitte (mit beliebiger Definition)
vertauschen will, brauche ich z.B. nur ein "rightof" durch ein "above"
austauschen und statt rechts-daneben (eben dem anderen "Objekt")
erscheint es dann oberhalb.

Ist also schon ganz schnuckelig.

Nur: Wie gestalte ich es mit Prioritäten, etc. ...
...muß ja ggf. auch später an verschiedene Ausgabeformate
(lout, LaTeX, TeX, Postscript, ...) angepasst werden.

Dann will ich da auch Sachen wie Alignment (center, left, right,...)
einbauen.
Das kann dann doch recht komplex werden.

Wo muß ich da auf bestimmte probleme achten, wo kann mir was auf die
Füße fallen?
Welche Art von Datentypen brauche ich in der Sprahce und wie
repräsentiere ich es innerhalb.

Arbeite ich eher mit Umgebungen, oder soll ich es eher OO-mäßig auslegen?
Evtl. beides, und man kann dann ggf. priorisieren (in welcher Weise)?

Die Sache mit den rekursiven Syntax-Beschreibungen muß ich mir anscheinend
auch noch mal rein ziehen (und die yacc-Ambiguities)....

Fragen über Fragen... ...bin aber froh, daß ich Samstag das immerhin so weit
schon hin gekriegt habe, daß das schon mal mit dem Konverter und Lout auch
zu ersten Ergebnissen in Form von Postscript-Ausgabe gereichte... :)

Es funktioniert schon mal in der minimalen Form, aber die ist halt nicht
ausreichend, um damit schon mal sehr komplexe Layouts einfach zu gestalten.
Da fehlt es noch so an Box-Internen Alignment-Funktionalitäten usw.
(Nimmt aber bereits jetzt schon sichtlich Arbeit ab für den bereich, der schon
möglich ist...)

Beispiel:
=================
monday = "Montag" above "Aufstehen" above "Kaffee kochen" above "arbeiten" above "schlafen gehen"
tuesday = "Dienstag" above "Ausschlafen" below "schlafe noch"

monday leftof (tuesday)
end
=================

Zwei Boxdefinitionen mit den Layoutanweisungen für die Boxes.
Dann die Konstruktion der Ausgabe des Layouts.
Dann den (bisher notwenigen) Ende-Marker, der die Ausgabe antriggert.
(Müsste ich nochmal schauen, ob ich das via eof steuere oder so.)

Ergebnis in lout wäre dann:

=================
@SysInclude {doc}

@Doc
@Text @Begin

monday = "Montag" above "Aufstehen" above "Kaffee kochen" above "arbeiten" above "schlafen gehen"
tuesday = "Dienstag" above "Ausschlafen" below "schlafe noch"

monday leftof (tuesday)
end
{{"Montag"} /1.0f "Aufstehen" /1.0f "Kaffee kochen" /1.0f "arbeiten" /1.0f "schlafen gehen"} |1.0f {"schlafe noch" /1.0f {"Dienstag"} /1.0f "Ausschlafen"}


@End @Text
=================

Ergebis in Postscript spare ich mir angesichts der Länge... ;-)


Naja, so ungefähr halt.... und wie sieht es denn aus mit Spracherrweiterungen?
Kann man die schonb vorab gut berücksichtigen?
Oder muß man dann ggf. alles wieder umbauen?

Wie sind da Deine Erfahrungen?


Gruß,
   Oliver