domain-specific languages



  • Hi!

    wann braucht man domain-specific languages?

    wiki sagt dazu folgendes:
    "Bei dem Entwurf einer DSL wird man bemüht sein, einen hohen Grad an Problemspezifität zu erreichen: die Sprache soll alle Probleme der Domäne darstellen können und nichts darstellen können, was außerhalb der Domäne liegt. Dadurch sind sie durch Domänenspezialisten ohne besondere Programmierkenntnisse bedienbar.

    Komponenten für eine DSL sind oft ein Parser, der die textuelle Repräsentation in einen internen abstrakten Syntaxbaum überführt und ein Interpreter, der den Semantikanschluss herstellt."

    was ist da mit Domäne, Domänenspezialisten gemeint?

    gibts sonst noch was zu diesem thema zu sagen?



  • Prinzipiell ist das ganze recht einfach zu verstehen.

    Stell dir vor du willst ein Framework entwerfen wo der Kunde Arbeitsprozesse mit beschreiben kann(natürlich nicht nur beschreiben sondern dein Programm soll danach dann auch handeln). Der Kunde will das natürlich nicht programmieren, er ist ja kein Entwickler, sondern er will das möglichst einfach irgendwie zusammenstellen. Also denkst du dir, hach, nehm ich doch einfach XML Dateien, kann man mit jedem Editor bearbeiten und mit nem ordentlichen Schema kann der Kunde auch nichts falsch machen. Und Voila, schon hast du ne DSL geschaffen 😉
    Die Dömane wäre in dem Fall das Beschreiben des Arbeitsprozesses(und auch nur dort ist dein XML ja dann sinnvoll), und die Sprache wäre in dem Fall der XML Dialekt denn du ja mit dem Schema festgelegt hast. Die Domainspezialisten wären in dem Fall die Anwender die solche Arbeitsprozesse beschreiben wollen. Die müssen nur wissen wie das XML aufgebaut werden muss, alles weitere interessiert die nicht.

    Nun ist XML natürlich nur eine Möglichkeit von vielen, natürlich wäre auch irgend ne eigene Scriptsprache möglich, aber das ist wieder mehr Aufwand, die meisten DSLs die ich gesehen hab waren irgendwelche XML Dialekte.



  • 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.
    meistens meinen leute aber mit DSL etwas was du tatsaechlich irgendwie durch nen interpreter jagst, und was eigenes verhalten hat, oder?



  • 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.


Anmelden zum Antworten