[linux-l] Grammar Design

Oliver Bandel oliver at first.in-berlin.de
So Sep 18 23:56:59 CEST 2005


On Sun, Sep 18, 2005 at 09:58:42PM +0200, Volker Grabsch wrote:
> On Sun, Sep 18, 2005 at 11:35:48AM +0200, Oliver Bandel wrote:
> > Naja, im Moment bin ich da noch ein bischen am herum probieren.
> > 
> > Will DSLs implementieren, in welcher Art... da schaue ich noch.
> 
> Werde mal bitte konkreter.

geht noch nicht.

Ist eben a process...


> 
> Bei mir gehen nämlich gerade die Alarmglocken an, dass du ein Problem
> lösen willst, dessen sich schon andere angenommen haben. Dann könnte
> deine Lösung an NIH erkranken.

Bitte erköär mal, was "NIH" meint.



> 
> > Welche Art von Parser/Grammatik liegt denn HTML/XML zugrunde?
> > Mit lex/yacc kann man das ja auch noch bearbeiten.
> > oder gibt es da schon besseres?
> 
> Na klar. Es gibt HTML- und XML-Parser. Bei den XML-Parsern gibt's
> sogar Standard-APIs, und zwar:
> 
> * SAX (für serielles Parsen)

kenn ick nich.
erklär mal.

gibt's da C- oder OCaml-Bindings?



> 
> * DOM (alles in den Speicher laden und dann in der Baumstruktur
>        rumwandern)


kenn ick nich.
erklär mal.

gibt's da C- oder OCaml-Bindings?


"DOM" hat aber nix mit Domina zu un.




[...]
> > Naja, ganz krass wird es natürlich, wenn man - z.B. für
> > Literate Programming Tools - verschiedene Kontexte hat,
> > in denen anders geparst/gelext(gescannt) wird.
> 
> In so einem Fall ist es am besten, für die "Haupt-Sprache" (die
> alles zusammenhält, ich vermute mal: XML) einen eigenen Parser
> zu nehmen, und die "Bruchstücke" dann durch ihre jeweils eigenen
> Parser nochmals zu jagen.

Die Haupt-Sprache (programmierer-seitig ist Ocaml; Anwednderseitig:
könnte halt was neues sein..).




[...]
> Wenn sich die Sprachen "vertragen", dann immer noch LR1.
> Ansonsten gibt es dafür irgendeine allgemeinere Sprachklasse,
> die aber dann nicht mehr viel aussagt.


? häh? Erklär mal allgemein-verständlich.


> 
> > Kann mir zwar denken, daß zu programmieren, aber welcher
> > Art Grammatik das ist, weiß ich nicht.
> > Vielleicht gibt's da ja schon fertig-Tools für?
> > (bezweifle ich aber... erst mal).
> 
> Ich vermute, dass es sogar Tools gibt, die dein gesamtes Problem
> lösen. Nenne mal bitte 2 oder 3 Beispiele, konkrete Anwendungsfälle.
> Wo siehst du ein Problem, wie willst du es lösen?

Hast Du noch nicht mitbekommen daß ich selber noch suche?



> 
> Eine extra neue Sprache ist i.A. keine gute Idee mehr. Schon gar
> nicht heutzutage, wo es schon viel zu viele ähnliche Sprachen gibt.


Du verstehst nicht.

Leider. :(



> 
> Nur, wenn du etwas *wirklich* Neues, Innovatives baust, dann
> könnte sich eine neue Sprachen lohnen. Aber selbst in diesem Fall
> wirst du dich in gewisser Form an existierende Sprachen und
> Paradigmen halten müssen, sonst droht das NIH-Syndrom.

...blah blah... was meinst Du?


> 
> > Das bedeutet aber für den Anwender der Sprache, daß er/sie/es diese
> > komplexe Sprache können müsste.
> > 
> > Ich finde aber, es macht keinen Sinn, eine DSL zu implementieren,
> > die einen bestimmten zweck erfüllen soll und dafür dann noch eine
> > allgemeine Programmiersprache verstehen zu müssen.
> > 
> > Das ist dann doch nur was für Programmierer, aber nicht für
> > Normalmenschen eines speziellen Anwendungsgebiets.
> > Da sollte schon was eigenständiges kreiert werden,
> > so daß die Benutzer nur in Ihrem Fachgebiet sich auskennen müssen
> > und dennoch ihre eigenen Skripte schreiben können.
> > Das ist ja der Sinn einer DSL (neben anderen Vorteilen).
> 
> Eine DSL sollte immer möglichst einfach sein. Aber was heißt schon
> "Domain Specific"? Meines Wissens nach sind die meistens "Domains"
> schon abgegrast.

Eben nicht.

Das Allgemeine ist - laut derzeitigem Stand der Wissenschaft - abgegrast.
Aber das spezifische eben nicht!

Und auch "das Allgemeine" ist im Wandel.



> 
> Nenn doch mal bitte konkrete "Domains", in denen du etwas vermisst.

Eben z.B. Movement Notation.

Kannst mir ja mal zeigen, welche der vielen Sprachen es da schon gibt.

Oder wie wäre es mit einer DSL zum deutschen Steuersytem?
Gibt's das schon alles?

OK, dann sach mal an, wo ich das downloaden kann...

...statt dessen gibt es ständig neue ALLGEMEINE Programmiersprachen,
aber nix, was man spezifisch einsetzen kann.




> Deine hier genannten Beispiel ist eher Negativ-Beispiele, wo du
> keine neue Sprache erfinden solltest.

Wie meinst Du das?


> 
> > So daß man in eingermassen verständlichen Anweisungen
> > die Filter definieren kann, und man bekommt ein Websieve-Script heraus.
> 
> Websieve kenne ich nicht, aber allgemeine Filtersprachen wird es wohl
> schon lange geben.

Eigentlich ganz ok, aber manches geht eben nur aufwendig.

Kennst Du also nicht, aber meinst, daß das kein Beispiel ist?  (tse!)



[...]
> Eine davon ist XML. Die ist aber nur sinnvoll, wenn du Text hast, der
> durch Sub-Elemente ("Tags") unterbrochen werden soll. Ist hingegen deine
> kleinste Einheit schon der Text (bzw. Zahlen), dann solltest du zu einer
> Sprache greifen, die leichter zu parsen /und/ menschenfreundlicher
> (d.h. editorfreundlicher) ist, z.B.:

Kann man in XML Funktionen definieren und nutzen?

Wenn ja: wie?

Wenn nein: vergiß den Scheiss!


 
> In jedem Fall brauchst und solltest du keinen eigenen Parser schreiben.

Ach was?

Dann erklär doch bitte mal, wie es anders gehen soll...



> 
> > Oder halt für andere beknackt gemachte Eingabesprachen.
> > Leider denken viele Programmierer nicht an die Anwender und machen
> > eigentlich leichte Sachen unnötig kompliziert in der Benutzung.
> > Oder lassen komplizierte Sachen auch kompliziert fpr den Anwender,
> > statt eine einfache benutzerschnittstelle zu schaffen.
> 
> Das kannst du Programmierern nicht immer vorwerfen. Es ist ein großes
> Design-Problem. Die Begriffe, die du hier anbringst ("einfach" -
> "kompliziert"), sind z.T. sehr subjektiv, und abhängig vom eigenen
> Wissensstand.

Eben. Deswegen kann ich als Programmierer in einer allgemeinen Programiersprache
auch nicht voraussetzen, daß sie diese Sprache verstehen.
Statt dessen nimmt man spezifische Sprachen (Excel, TeX/LaTeX, Gnuplot, ...)

Du meinst also, das wäre alles schon erledigt?

=> tja, Pech gehabt"

Die spezifische Domains wachsen sicherlich schneller, als die allgemeinen! :)

[...]
> Der Teufel steckt wirklich im Detail.

Ach neee... ;-)

Deswegen gibt es ja auch DSL's.
Weil es eben nicht angehen kann, daß ein Normalmensch mit Spezialgebiet
auch noch eine allgemeine Programmiersprache lernen muß!


[...]
> Wenn du diese sog.
> "Vereinfachungen" einfach aussummierst, ohne dir ein wirklich geniales
> Konzept dahinter zu erarbeiten, verschiebst du womöglich nur die
> Probleme, indem einfache Sachen noch einfacher werden, aber die
> komplexen Dinge unerträglich oder gar nicht mehr zu tun sind.

OK, dann implementiere Du mal die Sachen, die ich brauche... :)


> Du
> bekommst mehr Feature-Wünsche, und irgendwann wird deine Sprache
> wahrscheinlich noch viel wüster, als die ursprüngliche Sprache, die
> du vereinfachen wolltest. Das ist das NIH-Syndrom.

Naja, erzähl erst mal, was "NIH-Syndrom" meint.


[...]
> Meist reichen hierzu Templates, d.h. auch dafür brauchst du keinen
> Parser, denn Templating-Systeme gibt's ebenfalls genug.

Ja, mach mal ein Template.

Sach ma' wie's geht. ;-)


> > Aber das eine oder andere krassere teil schwebt mir da schon 
> > immer wieder im Kopf rum (z.B. auch Literate programming Tools).
> 
> Gibt's schon.

Na und?
Literate Programming Tools gibt es in der Tat, aber na und?
Das sagt ja nix darüber aus ob die Funktionalität das erbringt, was ich ha
ben will.


Wenn es schon alles gibt, was man haben will,
kann man ja ab sofort jegliche ENTWICKLUNG EINFRIEREN!

Also: damit erübrigt sich jegliche SW-Entwicklung.




> Auch hier: Wenn du was vereinfachen willst, nimm eine
> möglichst einfache Eingabesprache (ich bin für INI-Dateien, aber
> XML, YAML oder JSON tun's auch), und der Rest ist Aufgabe eines
> Template-Systems.


..bla.--


> 
> Übrigens ist es das, was (bezogen auf System-Administration) mit
> SuSEconfig probiert wurde, mehr oder weniger erfolgreich, da gehen
> die Meinungen auseinander.

erklär mal.


> 
> > Derzeit überlege ich, ob ich das Tool (Laban Scale Generator,
> >   siehe http://me.in-berlin.de/~first/labscalgen-invoke.cgi)
> > nicht doch eher HTML-/XML/LaTeX-like umbaue.
> 
> Wozu braucht man diese Laban-Symbole eigentlich?

Für Sachen, die man mit dem Computer nicht erfassen kann. :)



> Ein Link zu deine
> Seite mit Erklärungen (Wikipedia?) auf der Homepage wäre nicht schlecht.

Gibt eben noch nicht sehr viel dazu.

Aber als kleine Einführung wäre das hier vielleicht interessant:


http://www.gotan.ch/labanotation.html

http://user.uni-frankfurt.de/~griesbec/LABANE.HTML



> 
> Ich rate zu folgender Vorgehensweise: Schau, ob es für diese
> Laban-Symbole nicht schon ein Standard-Dateiformat gibt.

Dateiformat?

Ich glaube. daß Du nicht weißt, worum es geht...


[...]
> LaTeX-Support wäre am besten in Form eines LaTeX-Paketes,


zu kompliziert.

ich habe erwägt, statt eines kompletten Ausgabe-Dokumentes nur *.eps
heraus zu werfen. DAS könnte man dann mit LaTeX verarbeiten.
Aber diem vielen Windows-Nutzer habe da noch etwas andere Ideen dazu...



> welches
> diese Symbole bereit stellt, z.B. in Form von Makros.

Aha, Makros. Wie implementiert?
Gibt es ja schon alles?


> Was du dann
> als LaTeX-Code generierst, sollte dieses Paket dann einfach benutzen.
> Alternativ wäre eine Inline-Version natürlich auch gut. Es würde mich
> aber wundern, wenn es diese Symbole nicht schon längst in LaTeX bereits
> gäbe, sodass du direkt ein existierendes Paket benutzen kannst.


Na, dann kannste ja mal schauen, ob es das schon gibt.

Gibt's eben nicht!


Genau genommen war der labscalgen auch nur ein Projekt,
das einige Sachen implementieren sollte, die es noch icht gibt und
ausserdem dazu dient, zu eruieren, was denn praktikabel ist,.

Die Nutzer sind alle NON-LaTeX-User, die man erst mal langsam an das Prinzip des
Markups oder der Programmierungs-Herangehensweise heran führen sollte.

Das voraus zu setzen oder zu erwarten ist dumm.



 
> 
> Deine Scriptsprache halte ich für nicht unbedingt nötig.


Weil Du nicht weißt, worum es geht.

ich hatte zwar auch gedacht, viell. nur *.eps zu erzeugen.
Aber was macht denn ein Word-User mit *.eps ?!

Vermutlich in die Tonne schmeissen, genauso wie die SW, die das *.eps
erzeugt.



> 
> 
> 1. Fall:
> --------
> 
> Wenn du "Scipting"-Fähigkeiten willst, wieso nimmst du dann nicht
> eine Scriptsprache. z.B. in Python könnte das so aussehen:

Ich nutze Python nicht, und der End-Anwender will sicherlich auch kein
Python lernen müssen.


> 
> Du schreibst ein Modul "laban.py", dann könnte dein Script so aussehen:
> 
> 
> from laban import *
> 
> print(title, "Example of generated Scales")
> print(scale, D, R, H, DRF)
> newline()
> print(scale, F, B, R, L, H, D, RF, RB, LF, LB, HF, HB, DF, DB, HR, HL,
>              DR, DL, HRF, HRB, HLF, HLB, DRF, DRB, DLF, DLB)
> newline()


Aha, also eine andere syntax....

... und: warum also solltejemand diese NEUE SYNTAX lernen sollen?

Gibt's doch alles schon... 


[...]
> print(flipFB, scale, F, B, R, L, H, D, RF, RB, LF)
> newline()
> print(flipHD, scale, F, B, R, L, H, D, RF, RB, LF)
[...]


ausserdem: flip ist eine Funktion und scale dient zur Konstruktion eines
Datentyps...


Gibt es in Python eigentlich eine konsistente Handhabe diesbezüglich?


> 
> [...]
> 
> 
> Naja, ist noch nicht schön, ich willte nur das Prinzip verdeutlichen.
> "Sicher" ist das natürlich nicht, aber wenn es ne Scriptsprache werden
> soll, ist sowieso Vorsicht angesagt, da ist es IMHO besser, gleich von
> vornherein die Karten auf den Tisch zu legen ("das ist einfach nur
> beliebiger Python-Code"), als eine nichtvorhandene Sicherheit zu
> suggerieren.

scheiße, ey... dieses ganze Python-Gequatsche geht mir aber auf den Senkel!


Ich programmiere in OCaml. Na und?

Der Endanwender will weder Python noch Ocaml lernen müssen!

DESWEGEN ja auch sind DSLs sinnvoll !!!


> 
> Auf jeden Fall hättest du Schleifen, etc. schon geschenkt bekommen.
> Vielleicht würde der Kram in Lisp, Ruby oder Haskell sogar noch schicker
> aussehen. Einen eigenen Parser brauchst du jedenfalls nicht, und auch
> keine eigene Sprache.

blah.



> 
> 
> 2. Fall:
> --------
> 
> Willst du keine Scripting-Fähigkeiten, dann kannst du z.B. S-Expressions
> nehmen (bin mir nicht mehr ganz sicher):
> 
> (print title "Example of generated Scales")
> (print scale D R H DRF)
> newline
> ...
> 
> Bis auf diene Variablenzuweisung hättest du alles intus. (fügst du
> dann noch einen (let A B)-Befehl hinzu, und gehst konsequent weiter,
> landest du übrigens bei Lisp oder Scheme).  Natürlich wären JSON oder
> XML prinzipiell ebenfalls geeignet.
> 
> Auch hier brauchst du keinen eigenen Parser und keine eigene Sprache.

Das Problem ist doch wohl, was man für den Enduser imlementiert.

Oder habe ich was spezielles verpasst, was Python hier offeriert?


[...]
> Oder willst eine Scriptsprache. Dann nimm doch einfach eine, die dir
> gefällt, und schreibe eine Modul dafür.

Aha, erkär mal bitte in mehr detaillierter Weise.


> Um Kontrollstrukturen etc.
> brauchst du dich dann gar nicht mehr zu kümmern, du bekommst so viel
> geschenkt!


Klar... am besten alles schon voraus setzen. Dann eben Ocaml
nehmen und camlp4. Dann lernen die Leute erst mal eine allgemeine
Sprache - die sie nie wieder sonst brauchen - nur um eine spezielle
Sprache zu implementieren...


[...]
> > Das war in derzeitiger Version erst mal nur ein Start-Teil,
> > ein Erstversuch.  Aber einer, den man schon benutzen kann.
> > 
> > Immerhin kann man da nun auch Variablen setzen usw.
> 
> Da fängt's an.
> Vielleicht noch Schleifen?
> Wenn-Dann-Bedingungen?
> ...

Möglicherweise schon.

Aber es soll eben hauptsächlich spezifisch EIN SPEZIFISCHES Problem lösen.

Ja, ja, so haben viele Sprachen angefangen...
...aber aquch SQL ist demnach sinnlos, weil man das alles ja auch in Pascal
oder C machen kann...


...bitte schön: Viel Spaß dabei, semantische Inhalte emotionaler Gespräche über
eine Reihe von "1" und "0" codieren zu wollen!

Man braucht auch nicht C, wenbn man Assembler hat, und auch nicht OCaml oder Haskell, wenn
man C hat...


und auch nicht SQL, wenn man C hat,

und auch nicht gnuplot, wenn man LaTeX hat, 

...


usw.





[...] 
> Such dir eine schöne Sprache, und nimm diese als Basis für deine
> Überlegungen. Alle bisherigen Sprachen als "zu kompliziert" oder
> "anfängerunfreundlich" abzustempeln ist ziemlich arrogant, und
> meiner Meinung nach überhaupt nicht der Fall.

Sorry, aber Du verstehst nicht.


> 
> > Aber viell. wäre eine andere Syntax/Grammatik besser.
> 
> Warum nicht gleich eine andere *Sprache*?

eben!


> Warum nicht gleich eine schon existierende Sprache?


Wenn sie passt - gerne! :)



> 
> > Wird viellicht "inspired by" LaTeX, HTML/XML oder so.
> > Aber soll auch Möglichkeiten wie Makros/prozeduren/Funktionen zulassen.
> 
> Nein, *nimm* LaTeX oder HTML/XML oder eine andere geeignete Sprache, und
> *erweitere* sie.

Nö.

Ggf. wird *.eps in laTeX eingebunden...


> Wenn deine Sprache wächst, wird sie ohnehin an Komplexität
> zunehmen. Dann nimm lieber gleich ein etwas komplexeres System, da weißt du
> zumindest, dass du dich nicht verrennen wirst. "Yet another language" ist
> wirklich keine gute Idee. Du wirst viel Zeug nachimplementieren,
> wahrscheinlich in schlechterer Qualität, das es längst in den anderen
> Sprachen gibt.


Naja, wenn dem allen so ist: Das ganze Open Source Zeugs mit dem ganzen
source-Gemülle ist eh Quatsch!

WEG DAMIT!



[ so, jetzt muß ich mal bald in die Koje und deswg. viel Abkürzen ]




Alles in Allem habe ich den Eindruck, Du weisst icht, was das
Problem ist, was es zu lösen gilt, auch wenn klar ist, daß
eine DSl oftmals als kleines Dings tartet und als x-te
allgemeine Sprache endet.

Aber selbst das: ist eine kreative Möglichkeit, Neues zu schaffen :)

Gruß,
   Oliver



Mehr Informationen über die Mailingliste linux-l