domain-specific languages
-
geri1 schrieb:
es is eine (wenn auch kleine) sprache fuer die domain "application configuration". wenn man es ganz genau nimmt, is JEDE art von configuration file eine DSL, genauso wie vermutlich alle daten-dateien. is ein bisschen schwammig wo es anfaengt, wo es aufhoert.
Daten, die nur dein Programm versteht (Config-Files oder der interne Aufbau eines BMP), würde ich nicht als DSL bezeichnen. Eine DSL ist eher der Versuch, das Wissen eines Fach-"Experten" (und Nicht-Programmierers) in eine Form zu gießen, mit der du als Programmierer (bzw. dein Programm) weiterarbeiten kannst.
meistens meinen leute aber mit DSL etwas was du tatsaechlich irgendwie durch nen interpreter jagst, und was eigenes verhalten hat, oder?
Eigenes Verhalten ja, ein Interpreter muß nicht sein (du könntest auch die DSL-Anweisungen in ein C++ Programm umwandeln und compilieren).
-
"(du könntest auch die DSL-Anweisungen in ein C++ Programm umwandeln und compilieren)." wie geht das?
weil ich lese gerade hier:
- DSLs are called (at runtime) from programs written in General Purpose Languages like C or Perl, to perform a specific function, often returning the results of operation to the "host" programming language for further processing. Generally, an interpreter or virtual machine for the DSL is embedded into the host application.
oder man macht das so:
- DSLs are embedded into user applications, like macro languages within spreadsheets, and they are used to execute code that is written by users of the application, dynamically generated by the application, or both.
die macro sprache braucht doch auch nen interpreter?
-
geri1 schrieb:
"(du könntest auch die DSL-Anweisungen in ein C++ Programm umwandeln und compilieren)." wie geht das?
Mit viel Geduld
(wenn du willst, könnte man auch Yacc/Bison als Domänensprachen ansehen - die wandeln eine kontextfreie Grammatik (Domäne) um in ein C-Programm, das du anschließend compilieren und ausführen kannst)
-
geri1 schrieb:
die macro sprache braucht doch auch nen interpreter?
Du musst das ganze abstrakter sehen, da gibts zig ausprägungen und nur das Grundprinzip ist gleich. Wenn ich bei meinem Beispiel oben bleib mit dem XML Dialekt dann wertet dein Programm das XML aus und handelt danach. Das ganze kann natürlich beliebig komplex werden.
Das Prinzip von DSLs ist auch schon alt, DSL ist genauso wie z.b. SOA einfach nur nen Buzzword das gut klingen muss.
Es geht immer darum dass du ein konkretes Problembereich hast, für den du Lösungen finden musst. Nun könntest du diese natürlich in diesen general purpose Sprachen schreiben, aber die Sprachen bieten natürlich auch viel anderes Zeugs dass du für dein Problem gar net brauchst. Also vereinfacht man das ganze und entwirft eine Sprache die speziell deinen Problemfall bedient und gerade weil sie so speziell ist, nennt man dass halt domain specific. Wobei das vereinfachen auch relativ ist - DSLs können genauso beliebig komplex sein wie "normale" Programmiersprachen.
-
Geduld? hast du ein beispiel?
was ist eigentlich wenn ich python unter c++ verwende?
-
Boost.Proto ist eine Bibliothek um DSELs in C++ zu entwickeln.
wann braucht man domain-specific languages?
Eigentlich immer, wenn man einen Ablauf oder ein Model in einer Programmiersprache modellieren will. Nur unterstützen die meisten Programmiersprachen DSELs ziemlich dürftig und daher nutzt man diese ganzen unleserlichen und unwartbaren Methoden.
In dynamischen und symbolischen Sprachen wie zB Lisp ist es normal, dass man DSELs für Probleme schreibt. Das ist einfach die Frage ob man das Problem an die Sprache oder die Sprache an das Problem anpassen will
-
@Talla: das klingt einleuchtend!
@Rüdiger: Könnte man auch Boost::Spirit verwenden?
viele DSL sind einfach nur selbst-entwickelte script sprachen.
dh man kann auch DSL sachen unter bash, lua entwerfen?
-
geri1 schrieb:
@Rüdiger: Könnte man auch Boost::Spirit verwenden?
Boost.Proto ist eben für DSELs. Wenn du eine DSL parsen willst, dann kannst du Boost.Spirit nehmen. Spirit hat ja selbst eine DSEL. Das gab auch Anlass für die Entwicklung von Proto.
Im allgemeinen würde ich eher auf DSELs setzen, da man sich so viel Arbeit spart (parsen, code generieren etc.) und direkt auf eben der Programmiersprache arbeitet.
-
CStoll schrieb:
Daten, die nur dein Programm versteht (Config-Files oder der interne Aufbau eines BMP), würde ich nicht als DSL bezeichnen. Eine DSL ist eher der Versuch, das Wissen eines Fach-"Experten" (und Nicht-Programmierers) in eine Form zu gießen, mit der du als Programmierer (bzw. dein Programm) weiterarbeiten kannst.
Huh? Es heißt Domain Specific Language, nicht Nicht-Programmierende Fach-"Experten" Sprache.
-
ist boost da nicht wieder zu komplex?
...schoen wenn man ne allgemeine loesung fuer ein problem hat, aber gerade ne DSL is doch eben /domain/ spezifisch ... insofern wuerde eine allgemeine loesung extrem generisch sein muessen um ueberhaupt was zu bringen, und dann wird sie so komplex das man damit nix mehr anfangen kann?
-
geri1 schrieb:
ist boost da nicht wieder zu komplex?
...schoen wenn man ne allgemeine loesung fuer ein problem hat, aber gerade ne DSL is doch eben /domain/ spezifisch ... insofern wuerde eine allgemeine loesung extrem generisch sein muessen um ueberhaupt was zu bringen, und dann wird sie so komplex das man damit nix mehr anfangen kann?Ich verstehe nicht was du sagen willst. Schau dir lieber mal Boost.Proto an, anstelle wirr zu reden. (Nein, es ist keine allgemeine DSL, das wäre natürlich Schwachsinn. Es ist einfach eine DSEL um DSELs zu entwickeln.)
-
in der ponto doku steht http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/hello_world.html
The basic idea of expression templates is to overload all the operators so that, rather than evaluating the expression immediately, they build a tree-like representation of the expression so that it can be evaluated later.
hat das was mit dem prinzip des scanners siehe compiler zu tun?
-
boost ist doch mist. probier lieber das: http://www.ucalc.com/langbuilder.html
..................
..................
..................
..................
..................
..................
..................
..................
..................
..................
-
interessant was man dazu hört:
DSELs in C++, the Sad Truth
- Very difficult to design
- Code is hard to read and maintain
- Terrible compiler error messages
- So why not a DSEL for defining DSELs?!
- Expression construction
- Expression evaluation
- Expression introspection
- Expression transformation
-
finix schrieb:
CStoll schrieb:
Daten, die nur dein Programm versteht (Config-Files oder der interne Aufbau eines BMP), würde ich nicht als DSL bezeichnen. Eine DSL ist eher der Versuch, das Wissen eines Fach-"Experten" (und Nicht-Programmierers) in eine Form zu gießen, mit der du als Programmierer (bzw. dein Programm) weiterarbeiten kannst.
Huh? Es heißt Domain Specific Language, nicht Nicht-Programmierende Fach-"Experten" Sprache.
Richtig - und das bedeutet: Jemand, der sich in der Domäne auskennt, schildert die Aufgaben in einer Form, die er versteht (der "Kunde" in Talla's Beispiel könnte seine Probleme auch in C++ schildern, aber extra dafür C++ zu lernen will ihm niemand zumuten) - und die DSL verarbeitet das in eine Form, mit der der Rechner etwas anfangen kann.
-
CStoll schrieb:
Richtig - und das bedeutet: Jemand, der sich in der Domäne auskennt, schildert die Aufgaben in einer Form, die er versteht (der "Kunde" in Talla's Beispiel könnte seine Probleme auch in C++ schildern, aber extra dafür C++ zu lernen will ihm niemand zumuten) - und die DSL verarbeitet das in eine Form, mit der der Rechner etwas anfangen kann.
Das ist sicher ein Anwendungsfall, ja, aber dieser "Jemand" kann auch ein Programmierer sein, und die "Domäne" kann Konfiguration sein. Es geht nicht um
Programmierer v. Nicht-Programmierer
sondern um
General Purpose v. Domain Specific
-
*push*
ich interessieren mich auch für DSLs und hab mir nun endlich mal die zeit genommen, mich mit dem thema eingehender zu beschäftigen.
im moment schaue ich mir flex und bison an. naja, für einen kommandozeilen - taschenrechner reichts schon
was mich aber wirklich interessiert sind eigentlich keine wirklichen interpreter bzw. compiler für DSLs, sondern code - generatoren, die mir nur code-stücke erstellen, die ich dann im restlichen programm einbinde.
beispiel: eine einfache GUI beschreibungssprache, welche direkt in C++ code für ein GUI toolkit überführt wird, welcher im eigentlich programm eingebunden wird.ich bin mir noch nicht sicher, ob die diversen lexer/parser sachen das sind, was ich brauche.
eine andere alternative wäre ja zb. eine script-sprache wie perl, python oder prolog zu benutzen, welche auf basis einer DSL oder auch nur XML datei entsprechenden code rausschreibt. hab ich auch schon mit rumgespielt und schien für den zweck recht brauchbar zu sein.
-
@maximAL
Schau dir doch mal Boost.Proto an
-
rüdiger schrieb:
@maximAL
Schau dir doch mal Boost.Proto an
und den "
" hättest du dir nicht sparen können?
in diesem forum bekommt man entweder gar keine oder eine dämliche antwort. toll ist das.
übrigens war ich schon vorher so schlau, sonst hätte ich meine frage deutlich anders formuliert.
in diesem sinne:
-
IHMO ist in dem gesamten Thread eine Menge Bullshit geschrieben worden:
-
Eine DSL ist nichts anderes als ein Transformationspattern zwischen zwei Domain(Fach)modellen. Da steht nirgendwo geschrieben, dass am anderen Ende Code herausfallen muss. Ebenso verbreitet sind zum Bleistift M2M, M2Text, Text2M, Text2Text Transformationen.
-
Diese Domainmodelle entstammen i.d.R. aus dem Domain Engineering, weil eine DSL nur dann von Wert ist, wenn Sie oft genug wiederverwendet wird.
http://cis.cs.tu-berlin.de/Lehre/SS-03/Sonstiges/technInfo/TIS-SS2003-Folien2.pdf -
DSLs sind im Regelfall ein Satz von kommulativen Problemustern, die mit Constraints versehen werden. Problemmuster sind Konzepte die ursprünglich aus dem dem Lösungsraum stammen (Domainmodell).
-
Eine DSL hat auch nichts mit XML zu tunen. Dabei geht es nur um die Wiederverwendung der DSL in anderen Domainmodellen, wie es z.B. bei sematischen Netzen versucht wird.
-
Eine Konfiguration kann als Nutzung der DSL verstanden werden - im Application Engineering.
-
Für DSL libraries für GPLs sehe ich keine Existenzberechtigung. Das wird heute alles mit simpler M2T, T2T Transformation abgedeckt, z.B.:
http://www.eclipse.org/gmt/mofscript/
http://en.wikipedia.org/wiki/List_of_Eclipse_Modeling_Framework_based_software
Bonbon) http://elib.uni-stuttgart.de/opus/volltexte/2007/3237/pdf/diss_schrift_jost.pdf
-