wielang hat bei euch die entwicklung einer einfachen programmiersprache gedauert?



  • knivil schrieb:

    Der Contest dauert 72 Stunden.

    da hatt ich grad mal nen buggy parser fertig, der noch nicht mal sauber c-strings decoden konnte 😞

    sitz gerade am lexer (war zwar schon beim parse-tree(interpreter)), habs aber erstmal wieder verworfen bzw. auf eis gelegt um den lexer halbwegs sauber hinzukriegen. evtl. gehts beim 2.mal schneller.. beim erste mal läufts bekanntlich immer bischen holprig 😉

    wenn ichs bis zum ende des jahres hin bekommen sollte wär ich schon ganz glücklich^^



  • __-- schrieb:

    ...da hatt ich grad mal nen buggy parser fertig

    meinte natürlich nen tokenizer 🙄



  • __-- schrieb:

    sitz gerade am lexer (war zwar schon beim parse-tree(interpreter)), habs aber erstmal wieder verworfen bzw. auf eis gelegt um den lexer halbwegs sauber hinzukriegen. evtl. gehts beim 2.mal schneller.. beim erste mal läufts bekanntlich immer bischen holprig 😉

    Der Lexer ist doch eher langweilig. Mein Vorschlag ist, ihn so simpel wie möglich zu machen, solange er nur richtig funktioniert. Ich würde mir anfangs über die Laufzeit des Lexers keine Sorgen machen, das kann man immer noch nachholen. In welcher Sprache schreibst du das alles eigentlich?

    Bashars Skepsis ist schon gerechtfertigt, wenn ich auch noch den Scheme-Interpreter selbst schreiben würde und Real-World-Anforderungen an die Qualität hätte, wären wenige Tage sicher recht knapp bemessen.



  • mngbd schrieb:

    Der Lexer ist doch eher langweilig. Mein Vorschlag ist, ihn so simpel wie möglich zu machen, solange er nur richtig funktioniert.

    also ich denke ich hab da ein paar begriffe durcheinander gewürfelt. versuchs mal ohne die buzzwords... also soweit bin ich jetzt:

    1.   eingabe string in token wandeln         -> 90% fertig
    2.   token auf richtige reihenfolge prüfen   -> 30% fertig
    2/3. parse-tree erstellen                    -> 90% fertig
    4.   parse-tree optimieren                   -> 10% fertig
    5.   interpretieren                          -> 10% fertig
    6.   code generator                          -> 0%  fertig
    

    mngbd schrieb:

    In welcher Sprache schreibst du das alles eigentlich?

    hab mal in c angefangen (ja ich weiß dass es für sowas eher ungeeignet ist).



  • BTW: Warum nutzt ihr für solcherlei Arbeit nicht lex und yacc? Gerade den Tokenizer mit all seinen C-Übelkeiten zu schreiben ist in lex ja ein reines Kinderspiel. 😕

    MfG SideWinder



  • SideWinder schrieb:

    BTW: Warum nutzt ihr für solcherlei Arbeit nicht lex und yacc? Gerade den Tokenizer mit all seinen C-Übelkeiten zu schreiben ist in lex ja ein reines Kinderspiel. 😕

    MfG SideWinder

    ja beim 2. mach ichs evtl. mit den tools, wollts aber mal von hand gemacht haben. es geht ja auch darum was zu lernen und nicht es arbeitsmäßig möglichst schnell fertigzustellen.



  • __-- schrieb:

    hab mal in c angefangen (ja ich weiß dass es für sowas eher ungeeignet ist).

    Ich hab Scheme genommen, und mich über 2 Dinge gefreut: den Garbage Collector (ein altes Streitthema), und besonders über die Homoikonität von Lisp, die dafür sorgt, dass mein Syntax-Baum zugleich ein ausführbares Lisp-Programm ist.

    Ich empfehle, wenn es möglich ist, auf Optimierungen zu verzichten, um so schnell als möglich was am Laufen zu haben. Dann kommt der Spass nicht zu kurz.

    Vielleicht solltest du, da es ja nur um Übungen geht, einen Teil oder alles in einer abstrakteren Sprache als C machen. Ich persönlich zähle C nicht wirklich zu den Hochsprachen.

    SideWinder schrieb:

    BTW: Warum nutzt ihr für solcherlei Arbeit nicht lex und yacc? Gerade den Tokenizer mit all seinen C-Übelkeiten zu schreiben ist in lex ja ein reines Kinderspiel. 😕

    Der Lexer war mir bis jetzt einfach nicht wichtig genug. Die Schnittstelle zum Parser hab ich definiert, und dann einfach schnell mal den Lexer zusammengehackt. Wenn alles gut läuft und ich genug Freizeit locker machen kann, werde ich auf Dauer um einen ordentlichen Lexer nicht herum kommen.

    Einen Parser-Generator will ich nicht verwenden, ich mach das alles nur zur Übung.

    Nachtrag:
    Eigentlich hab ich mich über mehr als 2 Dinge gefreut, z.B. auch über die tail call optimization und die lambda's, ohne die ich keinen CPS schreiben kann.

    Korrektur:
    Das lambda an sich ist nicht wichtig, was wichtig ist, sind Closures.



  • Ich habe vor einiger Zeit einmal einen "Assembler-Interpreter"( 🙄 ) gebaut. Er liest aus einer Datei die nötigen Anweisungen, natürlich ohne .data Abschnitte zu beachten.
    Sowohl "Register" als auch einige Befehle wie add, mul etc. sind vorhanden. PUSH und POP sind ebenfalls vorhanden und manipulieren einen std::stack.
    Ich wollte immer eine Art "inline asm" hinzufügen (per Editbox direkt auswerten 🙂 ), habe es jedoch nie gemacht. Ein Spaß war's trotzdem...



  • Vicious Falcon schrieb:

    Ich habe vor einiger Zeit einmal einen "Assembler-Interpreter"( 🙄 ) gebaut.

    Hihi, sag einfach "virtueller Prozessor" oder "Bytecode-Interpreter" dazu, dann klingt es professioneller. Versuch dich mal an einer anderen Sprache, sowas ähnliches wie einen Lexer hast du ja schon.
    🙂



  • mngbd schrieb:

    Ich empfehle, wenn es möglich ist, auf Optimierungen zu verzichten, um so schnell als möglich was am Laufen zu haben. Dann kommt der Spass nicht zu kurz.

    ich wollts mit den optimierungen nicht übertreiben, wichtig wären mir für den anfang sowas wie constant folding und inline funktionen, denk das wird schwer genug 😞



  • __-- schrieb:

    ich wollts mit den optimierungen nicht übertreiben, wichtig wären mir für den anfang sowas wie constant folding und inline funktionen, denk das wird schwer genug 😞

    Constant Folding musste ich nachschlagen, bin kein Informatiker. Vielleicht werd ich irgendwann mal einer. Ich denke, wenn du alles richtig machst, sollten diese Optimierungen prinzipiell recht einfach machbar sein. Damit meine ich nicht, dass es einfach ist, Kandidaten für das Inlining zu erkennen, aber die Umsetzung der beiden am Baum sollte nicht allzu schwierig sein.

    Ob es sich lohnen würde, daraus ein Projekt im Projekte-Forum zu machen? Sicherlich würden dann einige bedenkliche Leute mitreden, aber vielleicht zahlt es sich aus. Wäre eine nette Sache, wenn man das entspannt angeht, und trotzdem genug guten Code zusammenträgt, um was ordentliches zu bauen. Spaghetticode dürfte dann aber nicht dabei sein.
    🙂



  • Bei einem reinen Interpreter würd ich mir solche Optimierungen sparen, was bringt das denn?



  • mngbd schrieb:

    Ob es sich lohnen würde, daraus ein Projekt im Projekte-Forum zu machen? Sicherlich würden dann einige bedenkliche Leute mitreden, aber vielleicht zahlt es sich aus. Wäre eine nette Sache, wenn man das entspannt angeht, und trotzdem genug guten Code zusammenträgt, um was ordentliches zu bauen. Spaghetticode dürfte dann aber nicht dabei sein.
    🙂

    ja, ist ne überlegung wert. denk aber dafür ists noch ein bischen zu früh (müsst erstmal aufräumen und paar spaghettis rausziehen 🤡 (bischen funktionalität bräucht sie auch noch...)).

    Bashar schrieb:

    Bei einem reinen Interpreter würd ich mir solche Optimierungen sparen, was bringt das denn?

    naja also ohne interpreter kann ich ja die optimierungen nicht durchführen, oder? btw. ich find die schon wichtig, sonst lässt sie sich ja gar so schlecht nutzen und eigentlich wollt ich sie dann schon mal gelegentlich produktiv einsetzen 😋



  • Ich hab ehrlich gesagt keine Ahnung, was du mir mitteilen willst.



  • Bashar schrieb:

    Ich hab ehrlich gesagt keine Ahnung, was du mir mitteilen willst.

    int mul(int x,int y){
      return x*y;
    }
    

    muß ich doch interpretieren, wie soll ich sonst rausfinden was "mul(2,4)" rausgibt? wenns fertig ist würd ichs schon mal gern verwenden, das wär dann der teil "spaß" (sonst geht der ja iwie ab) 😃

    @edit: evtl. fehlt auch der teil, dass ich es im anschluß an den interpreter auch mal ganz gern nativ compilieren würde. 😕



  • Ja Spaß hin oder her, aber ich sehe nicht, wieso da jetzt Optimierungen zwingend notwendig sind, um das produktiv einsetzen zu können? Zumal die, wie ich schon sagte, nicht so viel bringen wie bei einem Compiler. Oder anders gesagt: Die beste Optimierung für einen Interpreter ist, daraus einen Compiler zu machen 😉



  • ich würd dem c-compiler ganz gern gutes ausgangsmaterial übergeben, evtl. brauchts ihn ja dann iwann nicht mehr 🤡



  • Vicious Falcon schrieb:

    Ich habe vor einiger Zeit einmal einen "Assembler-Interpreter"( 🙄 ) gebaut. Er liest aus einer Datei die nötigen Anweisungen, natürlich ohne .data Abschnitte zu beachten.
    Sowohl "Register" als auch einige Befehle wie add, mul etc. sind vorhanden. PUSH und POP sind ebenfalls vorhanden...

    Das ist sehr geil; ich erinnere mich, wie ich vor vielen Jahren in den Ferien an einem sehr, sehr langweiligen Tag einen "Assembler-Interpreter" unter DOS mit PowerBasic geschrieben habe. Gewisse Befehle wie Interrupts wurden dabei direkt wieder in Maschinencode umgesetzt. Zeitaufwand für einen dummen, aber hartnäckigen Jungen: 6-8 Stunden.

    Was war das für eine Freude, als spät am Abend die ersten Grafiken gezeichnet werden konnten, nachdem folgende Zeilen "interpretiert" wurden:

    mov al, 13h
    xor ah, ah
    int 10h
    

    Und was hat es mir am Ende gebracht? Sehr viel, denn wie sinnlos die Entwicklung einer eigenen Programmiersprache auch sein mag, sie vermittelt einem das ganze Repertoir an Techniken und Abstraktion, die man als Entwickler auch sonst immer wieder brauchen wird.





  • _-- schrieb:

    ich würd dem c-compiler ganz gern gutes ausgangsmaterial übergeben, evtl. brauchts ihn ja dann iwann nicht mehr 🤡

    Verwendest du C als Zielsprache?


Anmelden zum Antworten