[linux-l] Grammar Design
Volker Grabsch
vog at notjusthosting.com
Mo Sep 19 05:50:17 CEST 2005
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.
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?
Beim Steuersystem, da weiß ich nicht genau,
was dir fehlt. Falls du Elster meinst: Da gibt es bereits eine XML-
basierte Sprache, die die Formulare beschreibt. Übrigens leidete Elster
früher auch an dem NIH-Syndrom, als sie das Datenformat, die
Übertragungs-Verschlüsselung, etc. "von Hand" definiert hatten. Aber mit
dem "Coco"-Projekt haben sie nun endlich ihr Dateiformat XML-basiert
gemacht und der Übertragungsweg ist glaubich SSL, etc. ... das macht
das Entwickeln von Clients überhaupt erst erträglich. Nur bei der
Verschlüsselung nehmen die irgendein komisches unübliches Verfahren.
Warum können sie nicht einfach die Steuererklärung über irgendeine
URL per HTTP-POST empfangen, gleich mit SSL, und dass man im
wesentlichen nur irgendsoeine XML-Datei hochlädt? Nein, sie müssen
es unbedingt umständlicher machen. Jetzt braucht man, obwohl das interne
Format wenigstens vereinfacht wurde, immer noch einen speziellen Client,
um das hochzuladen. Unbedingt bei den Protokollen was "eigenes" nehmen,
völlig sinnlos. Womit wir wieder beim Thema wären. ;-)
> > 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. Oder dass Teilprobleme
mit eigenen Lösungen angegangen werden, die schon lange gelöst sind.
Würden man wirklich *neue* Lösungswege einschlagen, also völlig andere
als die ursprünglichen Entwickler, wäre das in der Tat eine Innovation
und eine gute Sache. Das NIH-Syndrom beschreibt jedoch den sehr viel
wahrscheinlicheren Fall, dass man fast den selben Lösungsweg einschlägt
wie die ursprünglichen Entwickler, und all die Fehler in ähnlicher
Form wiederholen, und mit den gleichen Tücken kämpft.
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.
2) Sie sind in Sachen Dateiformat/Protokolle etc. inkompatibel zu dem,
was die ursprünglichen Entwickler gemacht haben.
Aus diesen Gründen ist das NIH-Syndrom als fortschrittsfeindlich
anzusehen. Diesem kann man begegnen, indem man zuerst schaut, was es
schon gibt, und die dahinterliegenden Ideen und Konzepte begutachtet.
Nur die Bereiche, in denen man wirklich andere, bessere Ideen hat,
die sollten verbessert / ausgetauscht werden. Alles andere sollte
man übernehmen, statt es "neu" zu machen. Sonst macht man seinen
Kram nur künstlich inkompatibel, ohne dass es irgendwas vereinfacht
oder verbessert.
Die ursprünglichen Entwickler haben die Probleme, mit denen die
zweiten Entwickler gerade kämpfen, wahrscheinlich schon längst gelöst.
Vielleicht ist das schon zu einem neuen Forschungsfeld geworden, wo
es bereits viele interessante Erkenntnisse gibt. Die zweiten Entwickler
hätten sich sehr viel Arbeit sparen können, wenn sie nur über ihren
Tellerrand geschaut hätten, und die Leistung der ursprünglichen
Entwickler anerkannt und untersucht hätten. Sind sie dann immer noch der
Meinung, dass es einen anderen besseren Weg gibt, dann nur zu! Durch
die Erfahrung der ursprünglichen Entwickler wissen sie nun auch, welche
Hürden und Ansprüche sie zu meistern haben, und auf welche Fallen sie
achten müssen, auf die sie vorher vielleicht gar nicht gekommen wären
(bzw. erst, wenn's zu spät ist und sie sich verrannt haben)
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.
> > 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.
Darüberhinaus kenne ich noch "expat", aber es gibt sicher noch viele
andere XML-Parser.
> > * DOM (alles in den Speicher laden und dann in der Baumstruktur
> > rumwandern)
>
> gibt's da C- oder OCaml-Bindings?
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". 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.
Schau dir das Expat-Projekt oder das Libxml-Projekt an, zum Thema
SAX und DOM hilft dir sicher auch Google weiter. 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.
> > 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.
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.
Nun kannst du bestende Werkzeuge miteinander verknüpfen, und brauchst
nichtmehr alles selbst zu machen.
> > Nenn doch mal bitte konkrete "Domains", in denen du etwas vermisst.
>
> Eben z.B. Movement Notation.
>
> Oder wie wäre es mit einer DSL zum deutschen Steuersytem?
> Gibt's das schon alles?
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.
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.
> ...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.
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.
> > 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.
> > > 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.
> > 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?
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>
Hey, das kannst du auf 100 verschiedene Arten machen. Das ist überhaupt
nicht die Frage! Die Frage ist, was dein Programm aus diesem XML-Code
macht. XML an sich legt nur die Grammatik fest, nicht die Struktur!
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.
> > In jedem Fall brauchst und solltest du keinen eigenen Parser schreiben.
>
> Ach was?
> Dann erklär doch bitte mal, wie es anders gehen soll...
Das habe ich! In der letzten Mail nannte ich dir Beispiele. In dieser
Mail nannte ich die Beispiele. Was erwartest du noch von mir? Wenn du
auf meine Beispiele nicht wirklich eingehst, dafür kann ich nichts.
> > 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.
> => tja, Pech gehabt"
>
> Die spezifische Domains wachsen sicherlich schneller, als die allgemeinen! :)
Ja, aber um sie zu lösen, muss man nicht immer wieder beim Urschleim
anfangen. Die "allgemeinen" Sprachen und Werkzeuge lösen nicht nur immer
mehr Probleme direkt, sondern sie vereinfachen sie auch immer mehr,
sodass das Lösen eines DS-Problems immer weniger Aufwandt mit sich
bringt, es sei denn, man lehnt Vorhandenes ab und will unbedingt alles
selbst machen.
In deinem Laban-Scale-Generator, parst du dort die CGI-Parameter per
Hand? Erzeugst du das PDF-File byteweise selbst? Nein? Aber die
Eingabe-Sprache, die muss unbedingt zu 100% selbstgestrickt sein.
Wozu? Damit tust du weder dir noch der Allgemeinheit noch den Usern /
Anfängern einen Gefallen.
> > Der Teufel steckt wirklich im Detail.
>
> Ach neee... ;-)
>
> Deswegen gibt es ja auch DSL's.
Nein, deswegen gibt es Libraries, Module, was auch immer, in den
jeweiligen Programmiersprachen ... bzw. in LaTeX gibt's für diesen
Zweck die Pakete.
> 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.
> [...]
> > 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.
> > > 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?
> 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.
> > Ü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.
In SuSE gibt's nen Haufen Konfigurationsdateien in einer "eigenen"
Sprache, wo im Prinzip nur ein großer Haufen an Variablen gesetzt wird,
die z.T. verschachtelt werden, damit man z.B. mehrere Netzwerkkarten
einrichten kann.
Ein Tool "SuSEconfig" liest diesen Ramsch ein, und erzeugt daraus
die "richtigen" Konfigurationsdateien (/etc/postfix/main.cf, ...),
die ja alle etwas verschiedenen aussehen. Im Wesentlichen sind das
einfach nur Standard-Konfigurations-Dateien für die jeweiligen Dienste,
mit Platzhaltern, wo dann die Werte der Variablen reinkommen.
Das ist ein typisches Beispiel für ein Templating-System. SuSE hat
das AFAIR mit Shell-Scripten gelöst (ein "sed" auf viele Dateien
reicht meist schon), vielleicht verwenden sie mittlerweile auch
andere Werkzeuge.
> > 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?
> 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. 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.
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.
Dein 2. Problem ist es, eine möglichst einfache Sprache zum Erstellen
von Choreographien zu haben. 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.
Du verquickst beide Probleme, wodurch du gezwungen bist, auch
komplizierte Anwendungen von Laban-Symbolen durch deine Choreographie-
Sprache zu implementieren. 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. Dann hast du ein zweites LaTeX
nachgebaut, oder ein zweites Lout. Das ist dann das NIH-Syndrom:
Du hättest es gleich als Font oder als LaTeX-Paket implementieren
können.
> [...]
> > LaTeX-Support wäre am besten in Form eines LaTeX-Paketes,
>
> zu kompliziert.
Wie löst du das denn derzeitig?
Davon abgesehen geht es in erster Linie um die Symbole, oder? Es gibt
doch TTF-Editoren ...
> 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.
> 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.
> > 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.
> 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. 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.
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.
Bei zweiterem Beispiel bräuchtest du nämlich nur noch etwas LaTeX-
Zeug drumherum packen:
\documentclass[...]{article}
\usepackages{labanscale}
\begin{document}
...
\end{document}
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.
Einziges Manko: Du müsstest ein LaTeX-Paket "labanscale" implementieren.
Aber es gibt ja noch andere TeX-Derivate und andere Textsatz-Sprachen,
die ebenfalls erweiterbar sind. Das heißt, du müsstest dich in andere
Werkzeuge einarbeiten, um dein Ziel zu verwirklichen.
Wenn ich wüsste, wie du die Symbole erzeugst (als Font? als Vektorgrafik?
als Bitmaps? direkt in die EPS-Datei reingemalt?), könnte ich dir
vielleicht besser helfen.
> > 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, kannst du auch alle möglichen anderen Formate erzeugen: PNG,
JPG, ... vielleicht gibt's sogar ne Library oder ein Tool, das dir daraus
WMF erzeugt, dann bleibt es sogar ne Vektorgrafik.
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.
> > 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.
Ist deine Sprache besser? Wenn er eine kleine Teilmenge von Python
lernt, hat er wenigstens Wissen erworben, das ihm nicht nur bei seinem
DS-Problem hilft.
> > 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....
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,
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". Auch dein letztes
Konstrukt ist sicher in irgendeiner Programmiersprache ein gültiger
Ausdruck (z.B. in Ruby), wenn du die Funktionen "print" und "title"
entsprechend implementierst.
Ist es wirklich dein einziges Problem, dass du eine Scriptsprache suchst,
die ohne Klammern auskommt?
> ... und: warum also solltejemand diese NEUE SYNTAX lernen sollen?
Die ist nicht neu. Das ist Python-Code. Gibt's seit 1995 oder noch
länger.
Und vorallem: Ist deine Syntax etwa irgendwo standardisiert? Die muss
doch ebenfalls als "neue Syntax" erstmal erlernt werden.
> [...]
> > 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?
Bis dahin sage ich einfach mal: Wahrscheinlich ja. :-)
> 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?
Was ist an Python komplizierter als an deiner Sprache? Die Klammern??
Das ist nämlich in den bisherigen Beispielen der einzige syntaktische
Unterschied!
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
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.
Selbiges gilt für alle anderen Scriptsprachen auch.
Dein Argument, man könne eine bestimmte Sprache nicht nehmen, weil
der User die gesamte Sprache lernen müsste, ist ungültig, weil der User
ja nur eine geringe Teilmenge dieser Sprache lernen braucht.
Das ganze hat den zusätzlichen Vorteil, dass der User mehr von der
Sprachen lernen kann, sobald er mehr Features braucht. Wenn du ihn
hingegen auf deine eigene Sprache fest-dongelst, ist er auf die Grenzen
deiner Sprache angewiesen, das bedeutet unnötige Arbeit für dich und
nutzloses erworbenes Wissen für den User.
So, ich hoffe, nun ist mein Einwandt endlich klar geworden. Genug
Beispiele habe ich in meiner letzten Mail und auch in dieser hier
wohl gebracht, oder?
> [...]
> > 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.
Habe ich, soweit es ging. Allerdings wenn ich mehr Details von deinem
Problem kenne, kann ich auch detaillierter auf die Lösung eingehen.
> > 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...
Nein, sie lernen eine Teilmenge dieser Sprache. Gerade soviel, wie sie
brauchen. Mehr nicht.
> 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.
Du hörst mir nicht zu, aber unterstellst *mir*, dass ich dich nicht
verstehe. So kann man nicht diskutieren.
> > > 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?
> > > 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.
Was dein "XML" angeht: Das kannst du nicht mit LaTeX und HTML in einen
Hut stecken. LaTeX und HTML haben bereits eine Struktur.
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.
> 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.
> Aber selbst das: ist eine kreative Möglichkeit, Neues zu schaffen :)
Ja, aber neues Nutzloses. Du reicherst damit den "OpenSource-Müll" an,
den du angeblich verabscheust. Eine weitere Dokumenten-Sprache, die
nichts wirklich vereinfacht ... wozu??
Übrigens habe ich einen Großteil deiner gehässigen Unterstellungen und
Beleidigungen diesmal noch ignoriert, in der Hoffnung, dass ich dir
vielleicht doch helfen kann. Trittst du meine Hilfsbereitschaft nochmal
mit Füßen, verbleibe ich mit EOD. So kann man nicht diskutieren. So
kann man nicht miteinander umgehen. Glaubst du, ich schreibe in dieser
Liste aus Langeweile?
Viele Grüße,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Mehr Informationen über die Mailingliste linux-l