domain-specific languages
-
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
-