Compilerbau Königsdisziplin?
-
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.
-
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.
-
!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.
-
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.
-
Wieso soll ein Makrosystem vermieden werden?
-
weil es ein Behelf ist. Um Sprachfeatures nachzurüsten oder Portabilität zu erzwingen.
-
!rr!rr_. schrieb:
weil es ein Behelf ist. Um Sprachfeatures nachzurüsten oder Portabilität zu erzwingen.
Und wo sind meine erhofften Gegenargumente?
-
da sind sie
1. Sprachfeatures per Makroprozessor nachzurüsten ist ein Behelf und schafft oft genug Schwierigkeiten, weil sich Makros nicht in die eigentliche Sprache integrieren.
Tip: Besser wäre, die notwendigen Features gleich einzubauen und in die Sprachsyntax aufnehmen.
2. Portabilität per Makros und Prä-Pro zu erzwingen - daß das nicht optimal sein kann, dazu reicht ein Blick auf die Makefiles und deren Prä-Files, aus denen sie generiert werden.
Tip: Besser eine Sprache von Anfang an portabel definieren, oder aber die Sprache nur dort einsetzen, wo sie portabel ist.
-
Nicht, dass ich mich hier beteiligen möchte, aber kann es sein, dass Du Makros mit "C-Makros" gleichsetzt? Diverse Lisps haben sehr schöne Makrosysteme, die nichts mit archaischen Präprozessor-Basteleien zu tun haben. Auch Polemiken sollten ein klein wenig recherchiert werden.
Warum Du Makefiles und Autotools durcheinanderwürfelst und hier als Argument bringst, verstehe ich auch nicht. Insbesondere nicht, wofür sie ein Argument sein sollen. Hat sich hier irgendjemand als m4-Fan geoutet? Wenn ja, wo?
-
Das weiß "!rr!rr_." doch, schließlich hat er sich als Fan von LISP und FORTH zu erkennen gegeben. Wobei Lisp als LISP zu schreiben aber ein ziemlich starker Indikator für keine Ahnung haben ist
-
schreib' das doch mal McCarthy, dem Designer von LISP und ein Autor des
LISP 1.5 Programmer's Manual
-
Oh, ein googelnder Traditionalist. Hast Du mal aufs Veröffentlichungsdatum von dem Ding geschaut? Weiß gerade nicht auswendig, ob das Ende der Fünfziger oder erst Anfang der Sechziger herauskam, aber so richtig taufrisch ist es nicht mehr.
Ich kann mich irgendwie des Gefühls nicht erwehren, dass Du mit Lisp-Makros nicht gerade auf Du und Du bist.
-
Damals war das ja auch noch in Ordnung. Bist du in den 60ern stehen geblieben oder hast du von der späteren Entwicklung etwas mitbekommen? LISP 1.5 hatte noch keine Makros. Das würde ja einiges erklären ...
-
nman schrieb:
Hast Du mal aufs Veröffentlichungsdatum von dem Ding geschaut?
Ja. Und?
nman schrieb:
Ich kann mich irgendwie des Gefühls nicht erwehren, dass Du mit Lisp-Makros nicht gerade auf Du und Du bist.
wie romantisch
-
a)
Bashar schrieb:
Wobei Lisp als LISP zu schreiben aber ein ziemlich starker Indikator für keine Ahnung haben ist
b)
Bashar schrieb:
LISP 1.5 hatte noch keine Makros.