[linux-l] Grammar Design

[Oliver Bandel]

Moin Volker,


danke für Deine Mühen mit mir. Ist manchmal sicherlich etwas
anstrengend. ;-)



On Mon, Sep 19, 2005 at 05:50:17AM +0200, Volker Grabsch wrote:
> On Sun, Sep 18, 2005 at 11:56:59PM +0200, Oliver Bandel wrote:
> > > > Will DSLs implementieren, in welcher Art... da schaue ich noch.
> > > Werde mal bitte konkreter.
> > geht noch nicht.
> > Ist eben a process...
> 
> Okay, lass mich das anders formulieren: Du möchtest "Domain Specific
> Languages" erschaffen, also domänen-spezifisch, das macht per Definition
> doch nur Sinn, wenn du bestimmte Domänen im Auge hast. Wenn du keine
> bestimmte Domäne im Auge hast, dann willst du etwas allgemeingültiges,
> domänenübergreifendes erschaffen, dann ist es aber keine DSL mehr.

Viele Domänen, viele DSLs.




> 
> Folglich muss es doch irgendwelche Domänen geben (zwei hattest du schon
> genannt: Mailfilter und Laban-Scale), bei denen du der Meinung bist,
> eine völlig neue Sprache mit eigenem Parser etc. würde irgendein Problem
> lösen. Du erwähnst noch das deutsche Steuersystem.
> Also, ist da nochwas, oder sind das erstmal nur diese drei Sachen?


Was das Steuersystem angeht, da meinte ich etwas, das
die gestzliche Struktur nachbildet.
Man gibt Kenndaten an und der Steuersatz oder die Steuerlast
wird ausgegeben.

Das ganze dann mit diversen Inputs gefüttert und man kann sich
als Ergebnis eine Grafik ausgeben lassen (gnuplot-Output oder so),
die anzeigt, wie der Steuersatz/die Steuerlast über den Parametern
variiert.

Ggf. mit genetischen Algorithmen optimierung der Belastung auf Minimum. :)


> 
> 
> > > 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.
> 
> NIH heißt "Not Invented Here". Das NIH-Syndrom beschreibt eine
> allgemeine Krankheit, an der viele Software-Projekte (vorallem im
> kommerziellen Bereich) erkrankt sind. Es geht darum, dass Dinge
> gebaut werden, die es schon lange gibt.

Klingt eher anders herum: NIH wäre erstrebenswert, denn man greift
auf Libs zurück, die not here invented wurden.

Dann sollte Deinen Aussagen nach ja eher NIH was feines sein und not-NIH das
Problem.


[...]
> Die "Nachbauer" haben damit die gleichen Vor- und Nachteile wie die
> ursprünglichen Entwickler, mit folgenden zusätzlichen Nachteilen:
> 
> 1) Sie haben alles nochmal implementiert, obwohl sich im Nachhinein
>    herausstellt, dass sie ja doch den Kram der ursprünglichen Autoren
>    direkten verwenden könnten.


Hat aber evtl. andere Vorteile.

Etwas in OCaml zu implementieren, was es in C schon gibt
hat den Vorteil, daß man da keine probleme mit Segfaults kriegt,
sondern einem sattdessen Exceptions gegeben werden.
Erst letztens las ich wieder eine Security Warning, wo es darum ging,
daß die pcre-Lib ausgenutzt werden kann, um User-Rechte zu erlangen.
Irgend eine Heap-Speicher-Problematik...

Sowas ist reichlich nervig.

Neu bauen macht ggf. also durchaus Sinn.

Neubauen kann auch Spaß machen und man was dabei lernen.
Auch ein Grund.


> 
> 2) Sie sind in Sachen Dateiformat/Protokolle etc. inkompatibel zu dem,
>    was die ursprünglichen Entwickler gemacht haben.

Wenn  man ein freies Format haben will, ist das ein Problem.
Aber vielleicht ist das ja auch gewollt...


> 
> Aus diesen Gründen ist das NIH-Syndrom als fortschrittsfeindlich
> anzusehen.

Aber nicht immer das schlechteste für den Geldbeutel. ;-)


 
> 
> In deinem konkreten Fall stört dich die Grammatik der bisherigen
> Sprachen, die du kennst. Wenn ich dich richtig verstanden habe, findest
> du sie umständlich und zu schwer für Anfänger zu erlernen. Das halte ich
> für einen großen Irrtum, weil es sehr viele sehr einfache Sprachen gibt,
> an denen du dich auch irgendwie orientierst. (ist bei deinem "Laban Scale
> Generator" sehr auffällig)  Jedoch konnte ich an deiner Sprache bisher
> nichts finden, das sie besser oder einfacher macht als bisherige Sprachen.
> Weder von der Grammatik her, noch von den Ideen, die du bisher angedeutet
> hast.


Komm einem Neuling in dieser Hinsicht mit "lerne doch Python" und er sagt,
daß er sich damit nicht auskennt. Besonders, wenn er Programmieren als
Wesensfremd zu dem ansieht, was er sonst den ganzen tag über macht.
Für's klicken halten sich die meisten Leute ja bereits fit genug,
aber programmieren? "Oh no!"

OK, aber ich verstehe, was Du meinst. Ich könnte statt meiner eigenen neuen Sprache
im Hintergrund Python laufen lassen, das hat eine Syntax, die meiner sehr
ähnlich ist und ich mache mir das Leben einfacher.
Darf ich dann aber nicht verraten, daß es sich um eine Programmiersprache
namens Pyhon handelt, sonst sind die Leute wieder abgeschreckt.
Ist leider so. Manche leute wollen zwar Programme benutzen, aber nicht
programmieren lernen.
Was meinst Du wohl, warum ich in dem Webformular bereits Beispielcode eingegeben habe?
Damit die Leute erst mal nur klicken brauchen.



> 
> > > Na klar. Es gibt HTML- und XML-Parser. Bei den XML-Parsern gibt's
> > > sogar Standard-APIs, und zwar:
> > > 
> > > * SAX (für serielles Parsen)
> > 
> > gibt's da C- oder OCaml-Bindings?
> 
> Ich habe in meinem vorherigen Posting von "libxml2" geschrieben, einer
> C-Bibliothek mit Wrappern für verschiedene andere Sprachen.

Aha.

Naja, ich habe irgendwo auch schon was von OCaml-XML-Libs gelesen.
Müsste ich nochmal schauen, wo das zeugs zu inden ist.


[...]
> Siehe oben. Die meisten XML-Libraries unterstützen SAX und DOM,
> meist weicht die API geringfügig ab.
> 
> > "DOM" hat aber nix mit Domina zu un.
> 
> "Document Object Model".

klingt gut. :)


> Das Dokument wird wiegesagt in den Speicher
> gelesen. Du hast dann ein Objekt, das das ganze Dokument darstellt,
> also das Haupt-Tag, und dann kannst du die Attribute anfragen, oder
> die Unter-Elemente durchlaufen, oder was auch immer. Du hast eben
> einen Objektbaum, die du durchlaufen kannst.

Aha, fein.


> 
> Schau dir das Expat-Projekt oder das Libxml-Projekt an, zum Thema
> SAX und DOM hilft dir sicher auch Google weiter.

Na, ich schaue mal nach den Ocaml-XML-Libraries.


> Es gibt es Netz
> darüber sehr viel bessere Texte, Tutorials, etc., als ich hier per
> Email auf die Schnelle zusammenbringen könnte. Und es ist wirklich
> nicht schwer.

Jau, na, dann schaue ich mal dort nach.



> 
> > > 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.
> 
> Ein Beispiel: Du hast XML, und willst C-Quellcode einbetten.
> Der Knackpunkt: In C hast du ein "<"-Zeichen, was dem XML-Parser
> eventuell nicht schmeckt.
> 
> Beispiel 1:
> -----------
> 
> <meindokument>
>   <script language="C">
> 
>      if (1<2) {
>        printf("Hello World!\n");
>      }
> 
>   </script>
> </meindokument>
> 
> 
> Hier vertragen sich beide Sprachen nicht. Das, was dort steht, ist
> kein gültiges XML, denn es wird ein Tag "<2) ..." geöffnet, und dann
> kommt Chaos. Der XML-Parser kommt damit nicht zurecht. Du kannst also
> nicht direkt den XML-Parser nehmen, sondern musst einen eigenen
> Parser schreiben, der ab dem Tag "<script ...>" umschaltet auf einnen
> anderen Parser, und bei "</script>" wieder zurückschaltet. Sehr
> aufwändig, und unter umständen keine schicke LR1-Grammatik mehr.

Ja, deswegen dachte ich daran, daß man einen Lexer/Parser baut, der dann
jeweils umschaltet auf andere Tag-Delimiter.
Das ist natürlich reichlich krass. Aber kann man schon bauen.


> 
> 
> Beispiel 2:
> -----------
> 
> <meindokument>
>   <script language="C">
> 
>      if (1<2) {
>        printf("Hello World!\n");
>      }
> 
>   </script>
> </meindokument>
> 
> Nun ist es ein gültiges XML-Dokument, weil das störende "<"-Zeichen
> gequotet ist. Nun kommt der XML-Parser damit klar, und du kannst
> z.B. nach dem Inhalt des Element "/meindokument/script" fragen,
> und er liefert dir den entsprechenden C-Code. Du kannst in diesem
> Fall also den fertigen, 1000x getesteten und stabil laufenden
> XML-Parser nehmen, und was er ausspuckt, jagst du durch einen
> C-Compiler oder C-Interpreter, derer es ebenfalls genügend gibt.


Oha. Coole Idee. :)

Ist natürlich eine feine Sache.

nur doof ist es, wenn man sowas von hand tippen muß.
Ein Nutzer, der das von hand editiert würde sich darüber aufregen,
daß man die Programmiersprache C in diesem Falle nicht 1:1 eingeben kann, wie man
es will.
Mal eben einen C-File hier einfügen geht nicht.
man muß dann erst den C-Code konverteirern.

Das ist dann wieder Anwender-Unfreundlich.

Auch, wenn die Idee ansonsten ganz cool ist.




> 
> Nun kannst du bestende Werkzeuge miteinander verknüpfen, und brauchst
> nichtmehr alles selbst zu machen.


Ja, das ist allerdings super-fein.

Aber der handeditierende Mensch, der das Zeugs eben nicht einfach mit
Copy&Paste aus der *.c-Datei hier einfügrn kann, der kotzt heftig ab.




[...]
> Nein, aber es gibt "general purpose" Sprachen wie z.B. XML, wo zwar
> die Grammatik feststeht, aber noch genug Spielraum vorhanden ist, um
> jede beliebige Datenstruktur abzubilden.

OK.

> 
> Sicher wäre es sinnvoll, einheitliche Datenstrukturen zu finden, das
> ist aber was völlig anderes, und dazu musst du heutzutage keine extra
> Sprache mehr "erfinden".
> 
> Genau das habe ich dir anhand deines Beispiels ausführlich und
> anschaulich erläutert. Es war dir nichtmal ein Kommentar wert!
> Was soll das? Was ist daran so schlimm, eine allgemeine Sprache
> herzunehmen, wie z.B. XML oder S-Expressions, oder eine
> Programmiersprache, und erst die /Struktur/ domain-specific zu
> gestalten? Dann brauchst du dich nicht um den Parser kümmern,
> und kann dich gleich auf das Wesentliche stürzen.


OK, verstehe, was Du meinst.


> 
> > ...statt dessen gibt es ständig neue ALLGEMEINE Programmiersprachen,
> > aber nix, was man spezifisch einsetzen kann.
> 
> Natürlich nicht. Deshalb sind diese "allgemeinen" Sprachen ja auch
> so flexibel gehalten! Dass du sie nämlich deinem spezifischen Problem
> entsprechend anpassen kannst. In Python schreibst du ein Modul. Und
> fertig.
> 
> In XML schreibst du eine DTD, dann ist der gesamte Parser schon fertig.

OK, das macht Sinn.



> 
> Was du hier heruntermachst, sind genau die Werkzeuge, die es dir
> ermöglichen, dass du eben nicht mehr im Urschleim (Sprachdesign,
> lex/yacc, ...) anfangen braucht, sondern dich gleich voll auf die
> Struktur und die Struktur-Manipulation stürzen kannst.

naja, to be honest, macht es mir auch Spaß, lex/yacc genauer zu kennen
und damit was zu implementieren. :)

Es war also mehr als nur der Wunch, schnell mal was Labansymbol-mäßiges
zu bauen. :)




> 
> > > Deine hier genannten Beispiel ist eher Negativ-Beispiele, wo du
> > > keine neue Sprache erfinden solltest.
> > 
> > Wie meinst Du das?
> 
> Das habe ich dir am Beispiel deines Laban-Scale-Generators doch
> versucht zu demonstrieren. Ich bekomme solangsam den Eindruck, dass
> du meine E-Mail wenn überhaupt nur überflogen hast. So kann man
> nicht diskutieren. Das ist beleidigend. Ich versuche, dir zu helfen,
> und du "hörst" nichtmal zu.


Sorry nochmals. ich war da gestern Abend in Zeitdruck und obendrein
krass dicht. Waren ein paar Bierchen zu viel gestern. War eine
schöne Galgenhumor-Wahlparty gestern. :)
Leider merke ich die Party heute noch... :(


> 
> > > > 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.
> 
> Nenn eine typische Konfiguration, die in Websieve zu aufwändig ist,
> und was du dagegen tun würdest. Ich bin mir sicher, dass eine neue
> Sprache weder notwendig noch sinnvoll ist.
> 
> > Kennst Du also nicht, aber meinst, daß das kein Beispiel ist?
> 
> Du wolltest eine einfachere Sprache definieren, mit der man "einfacher"
> seine Filterregeln beschreiben kann, und daraus Websieve-Code erstellen.
> Sicher gibt es da einiges zu tun, aber eine neue Sprache brauchst du
> ganz sicher nicht, das wäre sogar kontraproduktiv. Und ja, auch wenn
> ich nicht die syntaktischen Feinheiten von Websieve kenne, kenne ich
> trotzdem das grundsätzliche Problem.

Naja, für manche einfache Sachen ist mir XML einfach zu viel Tipperei.

Und was den Websieve angeht, da war nervig, daß die Regexp-Syntax es extrem
erschwert hatte, z.B. "*" zu matchen. Da musste dann ein aufwändiges
Konstrukt zusammen gebaut werden.

Da habe ich dann übrigens gedacht: Sch...., warum nutzen die nicht Perl-regexps
und Perl's eval?! :)

Und man könnte es aber mit anderen Sprachmöglichkeiten auch
versimplifizieren, indem man z.B. ein Keyword einführt, das andeutet,
daß das nachfolgende Regexp-Konstrukt oder Einzel-Symbol literal
zu nehmen ist und nicht als Wildcard.

Da haben die am falschen Platz gespart und hätten so eine Möglichkeit mit
rein nehmen sollen.



[...]
> Darum ging es bei dem, was dort steht, gar nicht. Davon abgesehen:
> 
> <meindokument>
>    <meinefunktion name="x1">
>      ...
>    </meinefunktion>
>    <meinefunktion name="abc">
>      ...
>    </meinefunktion>
> 
>    ..
> 
>    <rufefunktionauf name="abc"/>
> </meindokument>

Ja, sowas in der Art hatte ich mir auch überlegt.

Allerdings hätte ich den Tag-Parsser selbst gebaut.
Ist übrigens auch nicht sonderlich schwer.

Und interessant, das mal implementiert zu haben.


> 
> 
> Hey, das kannst du auf 100 verschiedene Arten machen. Das ist überhaupt
> nicht die Frage!

fein. :)

> Die Frage ist, was dein Programm aus diesem XML-Code
> macht. XML an sich legt nur die Grammatik fest, nicht die Struktur!

OK, ok.

Aber ist auch viel Tipperei.
Immer den Tag zum Öffnen der Umgebung und einen zum
Schliessen der Umgebung.

Da sind TeX's geschweifte Klammern wesentlich bequemer. :)
Man muß halt weniger tippen.

{\bf bold face}

statt wie z.B. in HTML

<b> bold face </b>






> Welche Tags es gibt, und wie du sie verschachteln darfst, etc., das
> kannst du selbst festlegen. Ein solcher Regelsatz führt dann zu XHTML,
> ein anderer zu SVG, u.s.w.


SVG sagt mir nix.


 
[...]
> > > 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?
> 
> Nein, ich meine, du brauchst keine extra neue Sprache.

ja, I see.

Bzw. Du meinst, ich brauche schon eine neue Sprache, aber
nutze dafür XML als Grundlage.


[...]
> In deinem Laban-Scale-Generator, parst du dort die CGI-Parameter per
> Hand?

Nö. Perl macht das.
use CGI;


> Erzeugst du das PDF-File byteweise selbst?

Nein.
Hatte ich auch schon überlegt, das pdf selbst zu generieren.
Ist aber doch etwas krass. :(

> Nein? Aber die
> Eingabe-Sprache, die muss unbedingt zu 100% selbstgestrickt sein.

Wenn das Stricken Spaß macht, was spricht dagegen?


> Wozu? Damit tust du weder dir noch der Allgemeinheit noch den Usern /
> Anfängern einen Gefallen.

Mir tue ich einen gefallen damit. Kenne mich nun mit lex/yacc ganz gut aus.
Besonders mit ocamllex/ocamlyacc. Super Tools! :)

Und Spaß macht's auch. :)


Wozu soll man ein Unix nachbauen, wenn es sowas schon gibt?
Und was ist draus geworden? Linux.
Wozu denn so einen Blödsinn veranstalten?




[...]
> > Weil es eben nicht angehen kann, daß ein Normalmensch mit Spezialgebiet
> > auch noch eine allgemeine Programmiersprache lernen muß!
> 
> Das ist wiegesagt Unsinn, weil deine sog. "allgemeinen
> Programmiersprachen" eben nicht schwer sind.


kommt drauf an, welche man nimmt.
Und kommt drauf an, wen man diesbezüglich fragt.

Aber die Python-beispiele sahen wirklich recht einfach aus.
Sogar sehr ähnlich dem, was ich da gebaut habe. Simmt schon. ;-)


> 
> > [...]
> > > 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... :)
> 
> Dann sag mir einfach, was du willst. So konkret werden deine Gedanken ja
> wohl schon sein.
[...]

Die Ausbildung zum Laban-Notator dauert einige Jahre.
Wenn man dann mal Leute fragt, wie die zum Computer stehen... *räusper*.

Es gibt einige wenige voin denen, die haben auch was eigenes implementiert.
Es gibt auch ein programm LabanWriter. Aber das ist letztlich bloß ein
Zeichenprogramm mit speziellen Symbolen.
Deswegen finde ich, muß eine Beschreibungssprache her, die für Laban-Scores nutzbar
ist. Diese gibt es aber noch nicht, und das wollte ich eigentlich den Spezis
überlassen (oder selber machen, wenn ich mal de Notator-Ausbildung machen würde;
müsste ich aber erst mal finanzieren können).

Aber ich kann natürlich das Tag-prinzip bei meinem generator ansetzen.
Naja, hatte ich ja schon drüber nachgedacht.

Hatte mir aber gedacht: lieber erst mal iregdnwas funktionierendes ins Netz
legen und feedback einholen, als das Perfekte niemals fertig ztu kiegen.

Wie man sieht, hat es mindestens eine Diskussion angezettelt.
Das war also schon mal sinnvoll so.


> 
> > > > 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.
> 
> Das ist was anderes. Hast du dir die bisherigen Werkzeuge alle
> angesehen?

Nicht alle, aber einige.
Es soll übrigens eines geben (habe ich noch nicht angeschaut), das
schon richtig krass ist und auch Definieren von Funktionen erlaubt
und krass verschachtelte Syntaxes... und das teil ist wohl sogar in Python
geschrieben.

Hatte bisher noch nicht angeschaut. Aber kann sein, daß dies Tool kann,
was ich denke, daß es können soll.

Habe leider nicht mehr im gedächtnis, wie das Teil hieß.
Liesse sich aber heraus finden.



> 
> > Wenn es schon alles gibt, was man haben will,
> > kann man ja ab sofort jegliche ENTWICKLUNG EINFRIEREN!
> 
> Nein, man kann sich die Arbeit erleichtern, weil die meisten
> Teilschritte, die man zur Lösung seines Problems benötigt, schon
> längst implementiert sind.

Ja, ok.


 
[...]
> > > Wozu braucht man diese Laban-Symbole eigentlich?
> > Für Sachen, die man mit dem Computer nicht erfassen kann. :)
> 
> Warum sagst du nicht einfach, dass man damit Choreographien erstellt?


Naja, eigentlich wird es bisher nicht hauptsächlich zum Erstellen von
Choreographien genutzt, sondern meist in einem archivarischen Herangehen.
Choreografien werden meistens zusammen mit den Tänzern/Tänzerinnen
in einem gemeinsamen Arbeitsprozess erstellt.

Mangels vorhandener Datenstrukturen ist es auch noch nicht möglich,
Choreografien mit Computerhilfe zu analysieren.
Die DTD läßt noch auf sich warten, obwohl immer wieder das Thema
mal angeschnitten wird, hat sich anscheinend bis jetzt noch nichts
brauchbares getan. Die Leute, die damit arbeiten nutzen also ihren Computer
bisher in einer Art und Weise, wie die Leute auch mit Word i.A. ihre texte schreiben.

LabanWriter ist eigentlich nur ein zeichenprogramm mit gesonderten Symbolen.
Man geht via Grafiksymbole, nicht via sematischer Struktur vor, obwohl die
Symbole ja eigentlich (je nach Symbol und auch Lage auf dem Score) semantisch
vollgepfropft sind.
Das ist aber auch ein problem: manche Sachen lassen sich nicht eindeutig
nur in ein Schema pressen. Das bedeutet, daß Mehrdeutigkeiten abgebildet werden
müssten.
Das macht die Entwicklung einer DTD wohl auch so schwer.

Immerhin gibt es wohl mittlerweile eine DTD für Musiknoten.
Aber eben noch n icht für Bewegungsnotation.

habe aber nochmal in der entsprechenden Mailingliste nachgefragt, ob sich
da mittlerweile was getan hat.

Ich denke aber mal, nicht.







> 
> > 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
> 
> Na bitte, das ist doch was.
> 
> Laban-Symbole sind also nur ein großer Haufen von Symbolen, die du
> irgendwie darstellen möchtest.

Das laß mal nicht die Labanotators hören. ;-)
Die wären jetzt zutiefst beleidigt. ;-)


> Dein "Laban-Scale-Generator" ist im
> wesentlichen ein Textsatz-System, das sehr primitiv im Vergleich zu
> TeX ist, aber dafür die Laban-Symbole beherrscht.

Es beherrscht ein Subset der Symbole.
Ein sehr geringes Subset.

Eiegentlich ist der laban-Scale-generator etwas, das die Leute
entwickeln müssten, die auch den LabanWriter entwickelt haben.
(Ohio State University).
Die können sich aber ihren Programmierer gerade mal für ein paar Stunden in der
Woche finanzieren.

Vielleicht müssten die ihrem Präsidenten klar machen, wie wichtig das für 
das Militär sein könnte, und dann würde das Geld fliessen. :->






> 
> Du hast also zwei verschiedene Probleme:
> 1. Erzeugung / Darstellung von Laban-Symbolen
> 2. Schreiben von Laban-Choreographien
> 
> Das 1. Problem ist allgemeingültig und sollte auch allgemeingültig
> gelöst werden. Ein TeX- oder LaTeX-Paket wäre nicht schlecht, oder
> ein TrueType-Font. Dann wäre der Grundstein dafür gelegt, dass erstmal
> jedes beliebig komplizierte Dokument deine Laban-Symbole enthalten kann.


Hatte mal andere Symbole (Effort-Graph) mit pstricks zusammen gebaut.
War aber auch alles nervig. Nicht alles an laTeX ist super.

Ausserdem brauchet ich komplexere Verarbeitungsmechanismen.
LaTeX als allgemeine Programmiersprche ist wohl reichlich ungeeignet.



> 
> Dein 2. Problem ist es, eine möglichst einfache Sprache zum Erstellen
> von Choreographien zu haben.

Nicht speziell zum erstellen von Choreographien.
Aber zum Setzen von Labanotation-Scores.


> Wenn du das 1. Problem gelöst hast,
> brauchst du an dieser Stelle nur eine beliebige Dokumenten-Sprache
> (wiegesagt, XML, YAML, JSON, S-Expressions oder was auch immer dir
> gefällt), den Parser hast du dann schon, und musst nur noch z.B.
> LaTeX-Code ausspucken.

OK.


Müste ich erst mal meine eigene DTD entwerfen.


> 
> Du verquickst beide Probleme, wodurch du gezwungen bist, auch
> komplizierte Anwendungen von Laban-Symbolen durch deine Choreographie-
> Sprache zu implementieren.

Naja, warum soll ich, wenn ich schon die Arbeit anderer mache,
das ganze kostenlos zur Verfügung stellen?
Wenn der Endanwender nicht alles geliefert bekommt, hat das auch den Vorteil,
daß er evtl. was löhnt, wenn er nicht selbst weiß, wie er das Problem lösen soll.

Die Leute an der Uni leben davon, die anderen Anwender leben davon,
und ich schreibe Tools in meiner freien Zeit, unbezahlt, und die
merits kriegen auch die anderen.

pöh!


> Wenn du also ein Buch über Laban-Symbole
> schreiben willst, wo diese Dinger ständig überall auftreten, wärst
> du gezwungen, deine Sprache zu stark zu erweitern, dass du damit
> ganze Bücher schreiben könntest.

Ach, auch eine gute Idee. :)
Ich schreibe da noch Bücher drüber.
Feine Sache! :)


> Dann hast du ein zweites LaTeX
> nachgebaut, oder ein zweites Lout. Das ist dann das NIH-Syndrom:

Das kann dann möglicherweise mein Portemonnaie gut gebrauchen.

> Du hättest es gleich als Font oder als LaTeX-Paket implementieren
> können.

1.: Nutzen die Leute das LaTeX eh nicht.
2.: Wenn die Software exklusiv ist, kann man die ggf. auch verkaufen.
    Oder Pay-per-Page.

Für mich selbst könnte ich das natürlich anders handhaben.


> 
> > [...]
> > > LaTeX-Support wäre am besten in Form eines LaTeX-Paketes,
> > 
> > zu kompliziert.
> 
> Wie löst du das denn derzeitig?

Ich habe da eine Datei labandirections.ml
Das sind 819 Zeilen Programmcode inklusive
Kommentare und reichlich Leerzeilen und
etwas totem Code.
Von den 819 Zeilen sind 456 Zeilen Postscript-Code.
In diesem Postscript-Code habe ich einen handwritten Type-3 Font
und ein bischen Basis für das ps-Dokument.

Das Programm erzeugt dann Postscript-Code.

Mit ps2pdf wandele ich das Ergebnis dann von postscript nach pdf.



> 
> Davon abgesehen geht es in erster Linie um die Symbole, oder? Es gibt
> doch TTF-Editoren ...

Hatte mal mit pfaedit herum gespielt.
Ganz schön krasses Teil.
Da bin ich ja mit handwritten Postscript erst mal schneller
voran gekommen.



> 
> > ich habe erwägt, statt eines kompletten Ausgabe-Dokumentes nur *.eps
> > heraus zu werfen. DAS könnte man dann mit LaTeX verarbeiten.
> 
> Vielleicht ist es einfacher, SVG zu erzeugen.

SVG?
Sacht mir nix.
Was'n das?


> 
> > Aber diem vielen Windows-Nutzer habe da noch etwas andere Ideen dazu...
> 
> Lass die Auflösung als Parameter, und erzeuge aus dem *.svg bzw. *.eps
> eine *.png-Datei. Dafür gibt's genügend Tools und Bibliotheken, die
> das machen.

Im Moment erzeuge ich eine komplette Postscript-Seite, nicht nur die Symbole.
Das mit dem *.eps war nur angedacht. Weiß noch nicht, ob ich das so machen werde.


> 
> > > welches diese Symbole bereit stellt, z.B. in Form von Makros.
> > 
> > Aha, Makros. Wie implementiert?
> > Gibt es ja schon alles?
> 
> War nur eine Vermutung. Ich wusste ja nicht, dass Laban so eine total
> unbekannte Sprache ist.

Laban ist keine Sprache. Laban war ein Mensch.
Labanotaion (Laban-Notation) oder in Europa die europäische
variante heisst Kinetografie Laban.


> 
> > 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.
> 
> Mag sein. Aber eine neue Sprache zu schreiben, in die sich die Leute
> einarbeiten, und die mit den Ansprüchen der Leute wächst, ist ebenfalls
> dumm.

Nein.

Das ist, wie man Leute erst mal an das Thema heranführen kann,
überhaupt mal was zu tippen, statt immer nur zu klicken.

Wenn Du manchen leuten sagst, sie sollten ihre texte programmieren, steshte
plötzlich allein auf weiter Flur.


> Denn ab einem bestimmten Grad an Ansprüchen, der gar nicht so
> weit oben liegt, hätte das Erlernen von LaTeX mehr Nutzen als Aufwandt
> gehabt. Außerdem kannst du ja ConTeXt oder Lout nehmen, die sind
> anfängerfreundlicher als LaTeX.


Naja, es hat eben auch noch andere Vorteile, wenn man was spezielles baut.



> 
> Nehmen wir z.B. das hier:
> 
> 	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
> 
> Da könntest du, abgesehen von Header und Footer, die immer gleich
> bleiben, folgendes machen:
> 
> 	title{Example of generated Scales}
> 	scale{\D \R \H \DRF}
>         \\
> 	scale{\F \B \R \L \H \D \RF \RB \LF \LB \HF}
> 
> Naja, oder so ähnlich. Und das wäre komplizierter? So viel
> komplizierter für Anfänger? Das ist IMHO genauso einfach wie
> deine eigene Sprache.

Nur ist das Schreiben von komplexen LaTeX-Makros schwieriger
als wenn man eine waschechte Programmiersprache nimmt.
Ausserdem: Der LabanScalegenerator ist zwar derzeit fast nur ein
Dokumentengenerator.
Aber erstens kann er jetzt schon mehr (flip-operationen sind bereits implementiert,
das ist eine Domain-spezifische Funktion) und soll später z.B. auch noch
dem Analysieren von Skalen dienen.

Dann ist man mit der LaTeX-only-Lösung schon wiedr auf dem falschen Weg.


[...]
> Dann brauchst du keinen Parser schreiben, dir keine Sprache
> ausdenken, und die Leute können schon etwas LaTeX, sodass sie, falls
> sie mal "mehr" wollen, einfach "mehr von LaTeX" lernen.
[...]

Das setzt voraus, daß es als reine Dokumentenbeschreibungssprache eingesetzt wird.
Das ist aber nicht der Fall.



 
> > > 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.
> 
> Du stellst dich da gerade etwas komisch an. Wenn du *.eps-Dateien erzeugen
> kannst,

Ich erzeuge aber garkeine eps-Dateien, das zu tun hatte ich aber überlegt.
ich erstelle ein komplettes Postscript-Dokuemntt, genau eine Seite.


[...]
> Andere Variante, wiegesagt: Erstelle einen Font, der die Laban-Symbole
> erhält.
> 
> In jedem Fall reduziert sich dein "großes" Problem auf ein kleines
> Problem, nämlich die "R, H, DRF" in entsprechende Sonderzeichen
> umzuwandeln, die durch deinen Font als Laban-Symbole dann auftauchen.


Wie gesagt, ich will spezielle Funktionalität einbauen.

Die flip-Anweisungen für das toggeln der Richtungen in allen
gewünschten Dimensionen ist so ein Dingens.
Das ist übrigens domain-spezifisch.


[...]
> > > 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....
> 
> Ja und? Du willst doch, dass der User sowieso eine neue Sprache lernen
> soll (nämlich deine selbstdefinierte). Da macht es für den Anfänger
> keinen großen Unterschied,


Na gut. Die Syntax ist sehr ähnlich.
So gesehen kann man das eigentlich übernehmen, da geb' ich Dir recht.

Den Lerneffekt "Implementierung eigener Sprache mit lex und yacc"
hingegen habe ich dann nicht. Naja, egal, das ist ja jetzt schon erledigt. ;-)



> 
> ob er nun [Python]:
> 
>    print(title, "Example of generated Scales")
> 
> oder [Lisp]:
> 
>    (print title "Example of generated Scales")
> 
> oder [deine Sprache]:
> 
>    print title "Example of generated Scales"
> 
> lernt. Alles ist gleichermaßen "leicht" bzw. "schwer".

Naja... hmhhh...


Man darf den leuten aber nicht sagen, daß sie da eine Programmiersprache lernen,
denn sonst machen die zu. Das muß dann nicht programmiersprache, sondern
Programm genannt werden. Und bedeienen tut man es, indem man so komische
Anweisungen da eintippt.
Dann sind auch Leute mit Technik-Angst davon zu überzeugen, das zu benutzen. ;-)

TeX/LaTeX sind jedenfalls als Programmiersprachen verschrien und viele Leute,
selbst welche, die wissen schaftlich arbeiten, würden da einen Bogen drum machen.
"Es war schon schwer genug, Word einigermassen zu beherrschen; dann fange ich nicht
noch an, eine programmiersprache zu lernen!"


[...]
> Ist es wirklich dein einziges Problem, dass du eine Scriptsprache suchst,
> die ohne Klammern auskommt?

Nein.

Aber ich finde es eigentlich ganz schön so. :)


[...]
> > [...]
> > > 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?
> 
> Sorry, ich habe deine Frage nicht ganz verstanden. Kannst du das nochmal
> genauer erklären?


Wie geht Python mit Types um?
Ocaml ist da sehr rigide. Das ist am Anfang krass nervig,
aber wenn man es erst einmal drin hat, dann ist es ausgesprochen
hilfreich.
Passt der Typ nicht, dann ist da was nicht in Ordnung. So kann
man die meisten programmierfehler, die man mit laxeren Sprachen
hat, ausschliessen.

"scale" nimmt z.B. hier nur Skalen-Definitionen entgegen.
flip-Funktionen nehmen Skalen entgegen und liefern Skalen zurück.
"print" kann verschiedene Typen ausdrucken.
...



[...]
> > dieses ganze Python-Gequatsche geht mir aber auf den Senkel!
> > Ich programmiere in OCaml. Na und?
> 
> Und ich in Python. Ersetze in meinen Texten Python gegen eine beliebige
> andere einfache Scriptsprache. Such dir eine schöne heraus. Die Auswahl
> ist groß genug.
> 
> > > 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?
> 
> Hast /du/ was spezielles an deiner Syntax, das Python nicht offeriert?

OK. I see.


> 
> Was ist an Python komplizierter als an deiner Sprache? Die Klammern??
> Das ist nämlich in den bisherigen Beispielen der einzige syntaktische
> Unterschied!

Nun gut.



> 
> Ein ungeheurer Vorteil von deinen verhassten "allgemeinen Scriptsprachen" 
> ist der, dass man auch nur eine Teilmenge benutzen kann. Um z.B. Python
> wie einen kleinen Taschenrechner zu benutzen, kannst du einfach das
> hier machen:
> 
> 	print ((3+4)*5+7)/6.56

Das zum beispiel wäre in OCaml nicht erlaubt.
Und ich weiß auch noch nicht genau ob ich sowas genehmigen würde.
(Wegen des Typs der zahlen: Integer und Float gemixt.

Wenn nicht, dann hätte ich da ein Problem: Wie verbiete ich der
Sprache, in die ich einbette, bestimmte ihrer Regeln nicht zuzulassen?

Definiere ich eine eigene Sprache, habe ich de Kontrolle darüber,
was geht und was nicht. Nutze ich eine andere Sprache als Grundlage,
geht auch alles, was diese Sprache erlaubt.
Es sei denn, ich filtere gewisse Konstrukte vorher raus und erlaube diese nicht.

Was, wenn jemand in dem Script module dazu lädt, Dateien einliest,
system(3) ausführen kann?!

Und wie kann man sowas verhindern, also den erlaubten Bereich der Sprache
begrenzen?

In Perl gibt's dafür Module - und die sind aber eigentlich
recht krass zusammen gefrickelt. Keine wirklich saubere Lösung,
geht aber wohl irgendwie.


> 
> bzw. wenn du den Python-Interpreter startest, kannst du dir sogar das
> "print" sparen. Du brauchst also nur soviel Wissen, wie du für den
> Windows-Taschenrechner bzw. Gnuplot brauchst. Um Python als
> Taschenrechner zu benutzen, brauchst du nicht die gesamte
> Programmiersprache "Python" zu lernen. Und genauso brauchst du
> nicht das gesamte "Python" zu lernen, wenn du Python als scriptbare
> Dokument-Sprache benutzen willst.


Wenn der Anwender es aber tut und dann mehr Möglichkeiten hat, als er haben
darf, kann er ggf. Dein System cracken.

Kein sicherer Ansatz.


[...]
> Das ganze hat den zusätzlichen Vorteil, dass der User mehr von der
> Sprachen lernen kann, sobald er mehr Features braucht.

Klar, system() und sudo und so...



[...]
> Wenn du ihn
> hingegen auf deine eigene Sprache fest-dongelst, ist er auf die Grenzen
> deiner Sprache angewiesen,

Und das ist auch gut so!


> das bedeutet unnötige Arbeit für dich und
> nutzloses erworbenes Wissen für den User.

Das bedeutet: eine sichere Applikation, die nicht jeden Befehl einer
all zu mächtigen Sprache erlaubt.

Man könnte natürlich auch im Web-Script die Befehle ausfiltern,
die verboten werden sollen...
... und dafür schreibt man dann einen eigenen lexer/parser ?!



[...]
> > 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...
> 
> So ein Unsinn! SQL ist ein völlig anderes Konzept. Eine neue Idee.
> Eine andere Ausdrucksweise. Etwas, was Pascal und C nicht bieten können.

Aha. Und das Vertauschen von Richtungen der Dimensionen ist nichts neues?
Was haben C, Perl, Python, ... mit bezüglich der Analyse von Skalen
zu bieten, oder bezüglich dem vertauschen von Richtungen einer Skala?

Das ganze wird mehr werden, als nur ein Textgenerator.



> 
> Du hörst mir nicht zu, aber unterstellst *mir*, dass ich dich nicht
> verstehe. So kann man nicht diskutieren.

Du gehst von anderen Vorausstzungen aus...


> 
> > > > 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! :)
> 
> Gut, na bitte, ich dachte schon, ich würde bei dir nur noch auf Ignoranz
> stoßen. Aaalso: Wieso "passt" Python nicht für deine Sprache? Welche
> syntaktischen / semantischen Konstrukte brauchst du denn, die dir
> keine existierende Sprachen bieten kann, bzw. was du in allen
> existierenden Sprachen nur umständlich umschreiben könntest?


Bin kein guter Python-Kenner, aber die Syntax sieht sehr einfach aus.

Es gibt aber, wie oben beschrieben ein Problem mit den zu vielen
Möglichkeiten. Ich will eben nicht, daß alles gehen darf mit der Sprache.
Das ist ein Sicherheitsloch.



> > > > Wird viellicht "inspired by" LaTeX, HTML/XML oder so.
> > > > Aber soll auch Möglichkeiten wie Makros/prozeduren/Funktionen zulassen.
> 
> LaTeX, wie jedes TeX-Derivat, beherrscht Makros/Prozeduren/Funktionen.

Die sind sehr viel schwieriger zu programmieren als wenn man das in einer
allgemeinen Programmiersprache macht.
Zumindest, wenn es über Kinkerlitzchen hinaus geht.

Hast Du schon mal in TeX eine Schleife geschrieben?
Und wie sieht das aus, wenn man da Prozeduren an eine
Schleife übergeben möchte?
Und so weiter...

...wer in TeX zum Beispiel seine Signalanalyse durchführt,
oder TeX als Spamfilter einsetzt oder als Webserver, der
hat da wohl etwas andere Interessen, als wirklich eine
solche Software zu erstellen.


> 
> Was dein "XML" angeht: Das kannst du nicht mit LaTeX und HTML in einen
> Hut stecken. LaTeX und HTML haben bereits eine Struktur.

Naja, aber das Prinzip eines Markup haben sie gemeinsam.
Das hatte ich gemeint.

Vermutlich würde am Ende ehz XML raus kommen, ohne daß ich damit
angefangten habe. Insofern ist Dein Einwand mit dem Wiedererfinden des Rades
vielleicht garnicht so verkehrt. ;-)
Andererseits ist's doch recht lehrreich und interessant, sowas mal
zusammen gebaut zu haben.


> 
> XML (und JSON, YAML, S-Expressions, ...) haben noch keine Struktur,
> sondern sind dahingehend völlig flexibel. Das macht diese Sprachen
> universell einsetzbar. Selbiges gilt für Datenstrukturen, wenn man sie
> in einer beliebigen Scriptsprache formuliert.


Vielleicht sind ja diese YAML und so etwas, was ich mir doch mal angucken
könnte.  XML natürlich auch.


> 
> > 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.
> 
> Genau darum geht es mir. Und ich habe dir Wege aufgezeigt, das du
> verhindern, auf die du leider nicht eingegangen bist.

Wenn ich eine eigene Sprache implementiere, kann ich genau festlegen,
was die kann und wie die aussieht. Nehme ich eine vorhandene, bin
ich dem ausgeliefert, was andere - für völlig andere Zwecke - mir
vorlegen.


> 
> > Aber selbst das: ist eine kreative Möglichkeit, Neues zu schaffen :)
> 
> Ja, aber neues Nutzloses.

Wieso nutzlos?
Wenn es benutzt wird, ist es nicht nutzlos.


> Du reicherst damit den "OpenSource-Müll" an,
> den du angeblich verabscheust.

Danke für die Blumen... *grrr*


> Eine weitere Dokumenten-Sprache, die
> nichts wirklich vereinfacht ... wozu??

Es ist eben nicht nur eine Dokumentensprache.
Eigentlich geht es eben auch darum, Analysen von
Bewegungssequenzen zu ermöglichen.
Wäre es nur ein reines Textsatzprogramm, hätte ich keine
Funktionen wie flip-RL oder flip-HD usw. implementiert.

Hatte schon vor längerer Zeit mal ganz andere krasse Sachen angedacht.
Aber da es kein vorhandenes Dateiformat gibt, das man sinnvoll benutzen kann
(ausser viell. die Dateien vom LabanWriter, die nun wirklich nur
Koordinaten von Symbolen angeben) musste ich halt erst mal irgendwas machen.

Also fange ich doch mit was kleinem an, schaue wie es sich benutzen lässt,
wie das Feedback ist usw.




> 
> 
> Übrigens habe ich einen Großteil deiner gehässigen Unterstellungen und
> Beleidigungen diesmal noch ignoriert,

Danke.

War im Suff raus gekommen, und mein Sorry habe ich schon ein paar mal
nun getextet.

> in der Hoffnung, dass ich dir
> vielleicht doch helfen kann.

Die Diskussion ist recht interessant.

Wie ich das dann letztlich realisiere, weiß ich noch nicht.


> Trittst du meine Hilfsbereitschaft nochmal
> mit Füßen, verbleibe ich mit EOD.

Nein, mache ich nicht...

Danke für die Diskussion.


> So kann man nicht diskutieren. So
> kann man nicht miteinander umgehen.

Ja, ok.


> Glaubst du, ich schreibe in dieser
> Liste aus Langeweile?

Weiß nicht. ;-)


Gruß und Dank,
         Oliver