[linux-l] Labanotation-Projekt (was: Grammar Design)

Fr Sep 23 20:41:37 CEST 2005

On Thu, Sep 22, 2005 at 06:32:42PM +0200, Oliver Bandel wrote:
> On Thu, Sep 22, 2005 at 02:49:34PM +0200, Volker Grabsch wrote:
> > Mit
> > allen Features, die eine Programmiersprache bietet, inkl. Aufrufen
> > von externen Filtern oder Berechnen von 100 Nachkommastellen von PI.
> > Aus dieser Sicht heraus wäre nämlich Python eine gute Wahl gewesen.
> > Und natürlich kannst du dann die Labanotation-Sachen nicht mehr als
> > Dokumente betrachten, sondern musst sie wie Programme behandeln, mit
> > allen Risiken, die das Starten von fremden Programmen nunmal beinhaltet.
> 
> Eben, das ist erstens zu viel, was nicht gebraucht wird, und zu
> riskant. Und was ich brauche, muß ich eh implementieren;

Also grundsätzlich erstmal: Ja und Nein.

Ja, du solltest das XML-Format von deinem Programm parsen lassen, und
Dinge wie "Makros" schnell selbst implementieren.

Nein, du brauchst keine Scriptsprache. Was du mir bisher genannt hast,
kommt dem auch nicht im Entferntesten nahe. Sicher, Makros kann man auch
als "Variablenzuweisung" oder "Funktionen" interpretieren. Aber das ist
auch schon alles an Ähnlichkeiten. Flip- und sonstwas für Aktionen waren
ja alles Textsatz (oder Grafiksatz), von daher weiß ich überhaupt nicht,
wieso du das Ding Scriptsprache nennst. Für mich ist das höchstens eine
"Dokumentsprache mit einfachen Makros". Mehr ist für den Anwendungsfall
auch gar nicht sinnvoll. Oder übersehe ich was? Dann klär mich bitte auf.

> ob nun in Python oder in OCaml.

Oh, du ziehst Python in Betracht? Cool. :-)

> > Aber wie ich mitbekommen habe, willst du gar nicht in dieser Laban-
> > Sprache programmieren.
> 
> Doch in gewisser Weise schon.
> Man braucht aber eben nur ein kleines Subset von Funktionalität
> einer allg. Sprache und dafür spezielle Features.
> Deswegen ja auch die Erwähnung einer DSL.

Ein mikriges Subset von Scriptsprachen.
Aber zu 99,99% eine Dokumentensprache, würd ich sagen.

> > Wahrscheinlich brauchst du überhaupt keine
> > Scripting-fähigkeiten,
> 
> Doch.
> 
> Wenn ich nicht nur eine Skala habe, sondern mehrere, und für alle
> (als Liste der Skalen) eine flip-RL Operation oder ähnliches durchführen will,
> dann ist das schon einiges notwendig an Sprach-Möglichkeiten.

Achso? Erklär mal bitte am Beispiel, und für welchen praktischen Zweck
das gut ist. Das läuft IMHO nicht auf Foreach-Scheifen, sondern auf
Filter hinaus, also Attribute bzw. Operationen eines höheren Knotens
des Dokument-Baums. Aber werd erstmal konkret.

> Mal schauen, viell. baue ich da selber was zusammen :)
> Eigene JavScript-Engine. Wieß ich aber nicht, ob ich dazu
> die Musse habe. Jednfalls könnte man damit nen super-krassen
> Web-Robot bauen. :)

Nee, so weit würde ich nicht gehen. Du brauchst offenbar kein
JavaScript, also implementiere auch kein ganzes. Wenn du's brauchst, dann
implementiere es nicht, sondern nimm es einfach. :-)

> > Aber wiegesagt, das brauchst du nicht,
> > wenn ich dich richtig verstanden habe.
> 
> Kein komplettes Python oder so.
> Ausser, man könnte die erlaubten Befehle limitieren.

Geht irgendwie. Ist aber IMHO nicht sinnvoll in deinem Fall.

> Aber mir steht der Sinn da eher nach Selbstbau.
> Dann habe ich da die Kontrolle, was das Teil kann und was nicht.

Da wäre ich vorsichtig. :-)

Ich finde, du solltest nicht in Richtung Scriptsprache denken, sondern
mehr in Richtung Dokumentensprache. Ich kann mir einfach nicht
vorstellen, was ein Labannotator mit ner Scriptsprache besser könnte.

LaTeX nutze ich ja auch nicht als Scriptsprache. Größere Sachen werden
entweder eh durch ein anderes Programm erzeugt, welches LaTeX-Code
ausspuckt. Oder ich komme mit einfachen Makros aus.

> [...]
> > Würde es nur um die Darstellung gehen, hätte ich dir sofort TeX oder
> > Lout empfohlen,
> 
> sind beide zu nervig.

Das war Konjunktiv. Ich empfehle es dir ja nicht. :-)

Höchsten als syntaktische Vorlage ist TeX ganz gut.

> Aber der Tip mit SVG war ganz gut.
> Vielleicht ist das einfacher als Postscript zu nutzen.
> Dann kommt ein Konverter dahinter (möglichst was fertiges)
> und der macht daraus ps/pdf.

Jap, so dachte ich mir das auch.

> > Viel "Programmieren" hättest du in TeX nicht müssen, IMHO.
> 
> Ist eben immer so eine Sache. Hat man eine leistungsfähige
> Ausgabesprache (*.ps, *.tex, ...) und macht dann die Ausgabe
> nur in lowlevel-Kommandos, erledigt man alles im Programm,
> vergibt man einige Möglichkeiten, u.a. auch die des nacheditierens
> von Hand.

Deswegen rate ich ja nicht zu PostScript, sondern zu LaTeX. Oder eben
SVG, wenn's dir was bringt.

> Soll heissen: Man kann komplexe Grafiken in Postscript auch als
> lines ausgaben, oder man kann komplexere Postscript-Operatoren
> anwenden.
> Baut man alles mit lines, muß man in der SW alles kontrollieren.
> Dann also auch z.B. Umbruch.
> Macht das die Ausgabesprache (Postscript oder TeX), ist es weniger
> Programmieraufwand in der SW, aber es wird kniffliger, wenn man
> in der möglicherweise schwierigeren Ausgabesprache alles umsetzen muß.
> 
> Bleibt wohl auch nur: ausprobieren.

Transparenz ist wichtig. Was hast du gegen LaTeX & Co. ?  Angenommen, du
hättest die Laban-Symbole als Font. Wäre dann LaTeX nicht die
angemessenste Ausgabesprache für dein Programm?

> > Deshalb brauchst du auf jeden Fall ein extra Format, das jeder parsen
> > kann und das lange Zeit möglichst einfach und stabil bleibt. Hier nimmt
> > dir XML sehr, sehr viel ab, deshalb habe ich "LabanXML" empfohlen.
> 
> Das soll aber high-level / semantisch sein, nicht nur die Grafikobjekte beschreiben.
> Sonst ist es kein Fortschritt gegenüber derzeitigen Ansätzen (LabanWriter).

Da bin ich auch dafür. Deshalb ja "LabanXML" :-)

Die XML-Sprache soll natürlich die Semantik beschreiben, so weit es
geht.

> > Hieraus kannst du dann z.B. LaTeX-Code erzeugen, es braucht nur
> > einfacher Code zu sein, denn alles, was ständig mit generiert werden
> > müsste,
> 
> Naja, gäbe es eine Laban-XML, so wäre auch das Analysieren viel einfacher.
> 
> Vielleicht sollte ich erst mal mit MusicXML herum probieren und schauen,
> was man damit so alles machen kann.
> Als Vorstufe für Laban-XML.

Ich wüsste gern, wo dein Problem ist. Du solltest doch kein Problem
haben, einfach mal eine DTD zu produzieren. Überlege dir eine Syntax für
die Symbole (hab ich dir ja demonstriert), und dann fasse sie erstmal
nur zu Zeilen zusammen, und schon bist du auf dem Stand des
Laban-Scale-Generators.

Am besten nimmst du erstmal ein konkretes Beispiel her. Irgendeine
Labanotation, die alle Features in Anspruch nimmt, die du haben willst.
Diese versuchst du dann, in XML zu beschreiben. Danach ergibt sich
die DTD fast automatisch. Du brauchst doch nur erstmal einen Startpunkt.

> [...]
> > Rotation und Spieleung von
> > Symbolen, vertikale Anordnung, .... das ist alles noch Textsatz.
> 
> Naja, wenn man stat Font dochGrafiksymbole nimmt, wäre es Grafiksatz.
> Bin mir noch unschlüssig...

Na gut, dann eben auch Grafiksatz .. hab das bisher zu Textsatz
dazugezählt, weil's LaTeX auch kann. Aber auf jeden Fall keine
Programmiersprache, oder? ;-)

> Für die einbfachen Skalen mit nur Richtungsangaben scheint aber der
> Ansatz mit Textsatz ideal zu sein.
> 
> Für die ausführliche Laban-Notation muß man dann doch auf Grafikbasis
> weiter machen (wegen der genauen Positionierung).

Was spricht gegen die \begin{picture} - Umgebung?
Wie schon oben gefragt: Wenn der Font da ist, biete dir LaTeX alles was
du braucht, oder?

> [...]
> > Schau dir SVG an, und dann kannst du immer noch entscheiden, wie du
> 
> Das scheint mir ein geeignetes Format zu sein, wenn ich Deine
> Ausführungen dazu betrachte.

Einen Font solltest du trotzdem bauen.

SVG ist geeigneter als PostScript, aber für deinen Zweck nicht unbedingt
besser als LaTeX.

> [...]
> > Eine editorfreundliche Sprache, die für Anfänger geeignet sein soll,
> > hat mir der ganzen Sache bisher nichts zu tun.
> 
> Doch.
> Ich will niemandem zumuten, sich direkt mit SVG beschäftigen zu müssen.
> Statt dessen High-Level Kommandos, wie z.B.: "move right leg up to 90 degrees".
> Dies könnte dann in ein XML-Format konvertiert werden.
> Ansonsten tippt man sich ja dämlich, wenn man die ganzen Tags
> schreibt.

Meine Rede! Genau das hab ich dir doch empfohlen. Ich meinte nur, dass
meine Ausführungen bis zu diesem Punkt, als ich das schrieb, noch
unabhängig von eben dieser "Enduser"-Sprache sind.

Ich hoffe, diesen Vorschlag ignorierst du nicht, sondern hilfst einfach
mal, den Vorschlag zu einer sinnvollen Sprache auszubauen. Einen TeX-Ansatz
und einen S-Expr.-Ansatz liefere ich mal:

---------------------------------------------------------------------

\skale{
	\symbol{move right leg up to 90 degrees}
	\symbol{move right leg down to 0 degrees}
}

---------------------------------------------------------------------

(skale
	(move right leg up to 90 degrees)
	(move right leg down to 0 degrees)
)

---------------------------------------------------------------------

Genauso hätten wir auch schon längst an dem XML-Format basteln können,
wenn du meine XML-Beispiele verbessert hättest, statt sie in der Anwort
wegzulöschen.

> > Wenn dieses Textformat
> > unbedingt selbstgestrickt sein soll, sollte es eine Teilmenge von einer
> > Textsatz-Sprache oder einer Wiki-Sprache sein ... idealerweise eine
> > Teilmenge von TeX. Aber S-Expressions oder ähnliche Sprachen sollten
> > schon komplett ausreichen, sind übersichtlich und erfüllen deinen Zweck
> > voll und ganz.
> 
> TeX reimplementieren?

Nein, nur deine Syntax, die du in LabanXML umwandelst, könnte eine
Teilmenge von TeX sein. Siehe obiges Beispiel. Oder eine S-Expr.-Sprache,
siehe 2. Beispiel.

> [...]
> > Du siehst, ich schlage eine starke Aufgabenteilung vor, um zu
> > verhindern, dass du zu viele Probleme in Verbindung bringst, die gar
> > nichts miteinander zu tun haben.
> Keine Sorge.
> Das Konzept steht schon seit ein paar Jahren, zumindest im groben.

Dann erzählt doch einfach mal. Oder stimmt es mit meinen Gedanken schon
überein?

> [...]
> > Nur eine interessante Querverbindung wäre noch denkbar und vielleicht
> > cool: Wenn die editorfreundliche Sprache nicht eine Teilmenge von
> > TeX wäre,
> 
> Nu' iß aber gut!
> Ich baue doch nicht TeX nach!?!

Nein! Nur syntaktisch daran festhalten. Siehe Beispiele.

Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR