Entwickeln einer Programmiersprache: Buchempfehlungen?



  • Ich habe mir als langfristiges Ziel gesetzt, eine eigene Programmiersprache zu entwickeln.

    Und ... du hast noch keine konkrete Vorstellung - willst aber Buchempfehlungen? Sag doch mal, was das werden soll. Ein wenig konkreter kannst du werden.



  • Wozu brauchst du dann ein Buch, wenn du if, loop und call hast? Und dennoch wuerde ich dir Forth und Scheme vorher als Uebung empfehlen.



  • knivil schrieb:

    Wozu brauchst du dann ein Buch, wenn du if, loop und call hast?

    Da muss doch mehr zu dem Thema sein, oder? Z.B. Multithreading, JIT, Optimierungen
    Ansonsten natuerlich noch Buecher zu Compilerbau. Und GCs sind auch ein Thema, von dem ich kaum Ahnung habe.



  • Sone schrieb:

    Ich habe mir als langfristiges Ziel gesetzt, eine eigene Programmiersprache zu entwickeln.

    Und ... du hast noch keine konkrete Vorstellung - willst aber Buchempfehlungen? Sag doch mal, was das werden soll. Ein wenig konkreter kannst du werden.

    Ich formulier meine Frage mal neu. Ich habe eine Sprache grossteils designt und mir als langfristiges Ziel gesetzt, diese zu implementieren. In welche Richtung es gehen soll, kannst du dir anhand der genannten Themen zusammenreimen.



  • Multithreading

    Nein, sind normalerweise Calls zu Kernelfunktionen. Klar kann man da ein Threadpool, Workstealing, ... drum bauen, aber das ist eher eine Library.

    JIT

    Ja, deswegen vielleicht Forth, einfach zu JITen.

    Optimierungen

    Ja, Tail-Call-Optimisation beispielsweise oder unboxing von primitiven Typen.

    GC

    Ja, deswegen Scheme, weils einfach ist cons-Zellen zu verwalten.

    kleinen Expression-Parser

    Na dann bastle doch dafuer erstmal einen JIT.



  • knivil schrieb:

    Multithreading

    Nein, sind normalerweise Calls zu Kernelfunktionen. Klar kann man da ein Threadpool, Workstealing, ... drum bauen, aber das ist eher eine Library.

    Vorausgesetzt, man mappt VM-Threads 1:1 auf native Threads. Das muss ja nicht der Fall sein.

    Den Rest werde ich mir ansehen. Forth sieht mir fast zu einfach aus, da sehe ich kaum potential, um etwas daraus zu lernen.



  • Kellerautomat schrieb:

    knivil schrieb:

    Multithreading

    Nein, sind normalerweise Calls zu Kernelfunktionen. Klar kann man da ein Threadpool, Workstealing, ... drum bauen, aber das ist eher eine Library.

    Vorausgesetzt, man mappt VM-Threads 1:1 auf native Threads. Das muss ja nicht der Fall sein.

    Nein, du hast wohl nur den ersten Teil gelesen. Man muesste mal direkt in die PPL oder TBB schauen, denn diese bieten solch ein Framework fuer C++.

    Forth sieht mir fast zu einfach aus, da sehe ich kaum potential, um etwas daraus zu lernen.

    Potential? Ich finde die Sprache elegant. Okay, bin kein Forthhacker, so dass ich Ecken und Kanten der Sprache nur schwer beurteilen kann.



  • Wie siehts aus mit Buchempfehlungen? <.<





  • Ich bin auf http://www.scifac.ru.ac.za/compilers/pdfvers.pdf gestossen. Bei durchscrollen durchaus ansprechend.



  • Kellerautomat schrieb:

    Ich formulier meine Frage mal neu. Ich habe eine Sprache grossteils designt und mir als langfristiges Ziel gesetzt, diese zu implementieren. In welche Richtung es gehen soll, kannst du dir anhand der genannten Themen zusammenreimen.

    Wo hast du denn Probleme?
    Der Parser sollte relativ trivial sein, wenn deine Sprache nicht völlig verkrüppelt designt ist (C++-Templates sind Horror zum Parsen, in D und Java gibt es da kein Problem).

    Der Rest ist eigentlich unabhängig vom Compiler, da geht es darum, wie du deine Sprachmittel implementierst. Dazu brauchst du dann Bücher über GCs, Erlang, etc., aber nicht über Compilerbau.

    Der schwierige Teil ist der Optimizer, aber den kannst du erst einmal weglassen.
    Wenn du entschieden hast, wie der AST aussehen soll, wüsste ich nicht, was dich aufhalten sollte. Dass Front-End und Back-End besser getrennt sind, versteht sich ja von selbst.


Anmelden zum Antworten