Compilerbau Königsdisziplin?

knivil

!rr!rr_. schrieb:

ich denke, es wäre eleganter, eine Hochsprache mit hinreichend flexibler Syntax herzunehmen und die DSLs in dieser Hochsprache zu formulieren, anstatt für jede DSL einen neuen Compiler zu bauen.

Ich entwickle also eine DSL (A), transformiere sie in die Hostsprache (B) und kompiliere sie in Binaerform (C, aber irrelevant). Der Prozess von A nach B ist ebenfalls eine Compilierung.

Die Syntaxen der genannten Sprachen sind nicht flexibel genug, man kann kaum neue Sprachelemente definieren, ohne die Sprache zu verlassen

Du sollst ja auch nicht die Hostsprache erweitern.

Intelligenz besteht für mich aus folgenden Komponenten:
- Die Fähigkeiten zu lernen

Nein. In dem Teilgebiet KI der Informatik macht das Thema "Lernen" nur einen geringen Teil aus. Intelligent bedeutet sowas wie schlau, ein Problem gut loesen. Ob die Loesungsstrategie gelernt, abgeschaut, in den Genen kodiert oder durch einen Algorithmus realisiert ist, spielt dabei keine Rolle. Verwechselt es nicht mit Bewusstsein!

Das Schwierige am Compilerbau ist doch nur der Optimizer?

knivil

Ist das eine Frage? Magst du vielleicht nochmal den Thread lesen? Kurz: Nein! Und "doch nur" laesst mich denken, dass du es selbst noch nie probiert hast.

Dann schau dir doch mal den Artikel im C++Magazin über Compilerbau an.

knivil

Dann beschaeftige dich doch mal ernsthaft mit Compilerbau. Das soll keine Kritik an den Artikeln sein, sie koennen allein vom Umfang her nicht mal die Spitze des Eisberges aufzeigen.

Compilerbau ist Compilerbau ob das nun in drei Seiten erklärt ist und dann auch inner Woche umgesetzt ist oder ob man einen wirklichen professionellen Compiler entwickelt ist doch Wurst. Sobald ein Programmen eine Programmiersprache in Maschinencode umsetzt haben wir einen Compiler vorliegen.

Also Compilerbau überhaupt nicht schwer, aber wenn es wirklich professionell werden soll dann wird es, wie mit fast allem, extrem komplex.

Compilerbau Königdisziplin?
Nein, vom Grunde her eine relativ einfache Geschichte welche aber je nach Anforderungen zu einer Königsdisziplin werden kann. Genauso ist es bei Spieleentwicklung, OS-Entwicklung etc.

Zeus

compilernerd schrieb:

Compilerbau ist Compilerbau ob das nun in drei Seiten erklärt ist und dann auch inner Woche umgesetzt ist oder ob man einen wirklichen professionellen Compiler entwickelt ist doch Wurst. Sobald ein Programmen eine Programmiersprache in Maschinencode umsetzt haben wir einen Compiler vorliegen.

Also Compilerbau überhaupt nicht schwer, aber wenn es wirklich professionell werden soll dann wird es, wie mit fast allem, extrem komplex.

Compilerbau Königdisziplin?
Nein, vom Grunde her eine relativ einfache Geschichte welche aber je nach Anforderungen zu einer Königsdisziplin werden kann. Genauso ist es bei Spieleentwicklung, OS-Entwicklung etc.

Du stellst deine Ahnungslosigkeit gerne so zu schau?

berniebutt

Die Krux ist wohl, wenn ein Compiler sehr viel mehr als nur die optimierte Umsetzung von standardisiertem Quellcode (Beispiel C oder C++) in ausführbaren Maschinencode leisten soll. Für mich ist das bereits das Drumherum, was man auch gerne haben möchte.

Erweitere ich die Anforderungen an einen Compiler in die spezifischen Anwendungen hinein, wird die Angelegenheit sehr komplex!

Ach, wie war es doch zudem mit Assembler, FORTRAN, PASCAL, und auch C so bequem! :p Man hatte nur einen Compiler und brauchte nicht für neue Ziele gleich einen neuen Compiler suchen oder gar selbst entwickeln müssen.

knivil

je nach Anforderungen zu einer Königsdisziplin werden kann.

Ich zitiere mich mal selbst:

Auch sind die Anforderungen gestiegen: man moechte gern ...

Desweiteren habe ich schon den naiven Ansatz diskutiert.

Zeus schrieb:

compilernerd schrieb:

Compilerbau ist Compilerbau ob das nun in drei Seiten erklärt ist und dann auch inner Woche umgesetzt ist oder ob man einen wirklichen professionellen Compiler entwickelt ist doch Wurst. Sobald ein Programmen eine Programmiersprache in Maschinencode umsetzt haben wir einen Compiler vorliegen.

Also Compilerbau überhaupt nicht schwer, aber wenn es wirklich professionell werden soll dann wird es, wie mit fast allem, extrem komplex.

Compilerbau Königdisziplin?
Nein, vom Grunde her eine relativ einfache Geschichte welche aber je nach Anforderungen zu einer Königsdisziplin werden kann. Genauso ist es bei Spieleentwicklung, OS-Entwicklung etc.

Du stellst deine Ahnungslosigkeit gerne so zu schau?

Na, dann erklären sie Herr Klugscheißer doch mal für die Allgemeinheit ab wann man ein Programm einen Compiler nennen kann.

knivil

compilernerd schrieb:

Na, dann erklären sie Herr Klugscheißer doch mal für die Allgemeinheit ab wann man ein Programm einen Compiler nennen kann.

Darum geht es doch gar nicht in diesem Thread.

Du sollst ja auch nicht die Hostsprache erweitern.

doch, gerade das ist wünschenswert - interne DSLs sind eleganter und einfacher zu implementieren als externe DSLs.

- und da kommt man mit den genannten Java oder Haskell etc nicht weiter. Mit syntaktisch flexiblen Sprachen wie LISP oder FORTH aber schon.

Zeus

!rr!rr_. schrieb:

Du sollst ja auch nicht die Hostsprache erweitern.

doch, gerade das ist wünschenswert - interne DSLs sind eleganter und einfacher zu implementieren als externe DSLs.

- und da kommt man mit den genannten Java oder Haskell etc nicht weiter. Mit syntaktisch flexiblen Sprachen wie LISP oder FORTH aber schon.

Die Anforderung bestimmt ob es wünschenswert. Dein Wünschenswert ist aus dem Brauch heraus, wie du es gerne siehst.
Ein Problem hab ich schon genannt, dass die Konflikte zwischen Hostsprache und DSL kommen könnte. Ein Weiteres ist, dass das man überhaupt nicht die Mächtigkeit der Hostsprache braucht und die Reduzierung auf die DSL Einfachheit bringen würde.

Ein Weiteres ist, dass das man überhaupt nicht die Mächtigkeit der Hostsprache braucht und die Reduzierung auf die DSL Einfachheit bringen würde.

es zwingt ja niemand den Benutzer einer internen DSL, den Rest der Hostsprache mitzubenutzen, wenn er das nicht braucht.

Praxisbeispiel: man kann perfekte Dokumente in LaTeX herstellen, ohne jemals auf "rohe" TeX-befehle zurückgreifen zu müssen. Niemand zwingt einen LaTeX-Programmierer, "rohe" TeX-Befehle zu benutzen, wenn er sie nicht braucht.

Ein Problem hab ich schon genannt, dass die Konflikte zwischen Hostsprache und DSL kommen könnte.

dieses Problem wird umso unwahrscheinlicher auftreten, je minimaler die Syntax der Hostsprache ist. Bei den genannten FORTH oder LISP dürften kaum Kollisionen vorkommen, denn man kann ja fast alles selber definieren.

knivil

Dennoch gibt es Probleme, wenn Schluesselwoerter der Hostpsrache mit denen der DSL kollidieren. Und zu Haskell: Man hat sich bewusst gegen ein Makrosystem a la Lisp/Scheme entschieden, wobei PLT-Scheme/Racket noch einen Tick drauf setzt. Man geht einfach einen anderen Weg, selbstverstaendlich kommt man Java oder Haskell genauso weit, auch wenn in Java nicht ganz so komfortabel. Beieindruckend finde ich http://video.google.com/videoplay?docid=2474684021522878343# , wobei es eher was mit Compilerbau als mit DSL oder Makrosystem zu tun hat.

Haskell *kotz programmiert da echt jemand freiwillig mit?

knivil schrieb:

Dennoch gibt es Probleme, wenn Schluesselwoerter der Hostpsrache mit denen der DSL kollidieren.

mag sein - wenn man es darauf anlegt. Muß man bei einer DSL, die LISP-intern realisiert wird, unbedingt die runde Klammer brauchen? Es dürfte machbar sein, dann eben die eckige oder geschweifte zu nehmen, wo die runde Klammer in LISP nunmal bereits vorbelegt ist.

LaTeX, um im praktischen Beispiel zu bleiben, fügt HUNDERTE neuer Befehle teils mit komplexen Sub-Syntaxen (z.B. array-Umgebung) zu TeX hinzu, und es gibt nur höchstens eine Handvoll Kollisionen (TeX-Befehle, die mit LaTeX vermieden werden sollten).

knivil schrieb:

Und zu Haskell: Man hat sich bewusst gegen ein Makrosystem a la Lisp/Scheme entschieden, wobei PLT-Scheme/Racket noch einen Tick drauf setzt.

Makrosysteme in Programmiersprachen sollten eigentlich sowieso vermieden werden. Sorgfältiges Sprachdesign vorausgesetzt, kommt man ohne Makrosysteme und ohne Prä-Pros aus.

Zeus

Wieso soll ein Makrosystem vermieden werden?

weil es ein Behelf ist. Um Sprachfeatures nachzurüsten oder Portabilität zu erzwingen.

Zeus

!rr!rr_. schrieb:

weil es ein Behelf ist. Um Sprachfeatures nachzurüsten oder Portabilität zu erzwingen.

Und wo sind meine erhofften Gegenargumente?