Python-Interpreter in 1024 Bytes C-Code
Making a Python interpreter in 1024 bytes
Austin Z. Henley hat sich einer Herausforderung gestellt: einen Python-Interpreter in nur 1024 Bytes C-Code zu schreiben. Sein Ansatz: Statt den vollen Sprachumfang zu implementieren, konzentriert er sich auf eine Teilmenge, die Python ähnlich sieht – inklusive Einrückungen, if/else, while, for und Funktionen. Der Parser arbeitet direkt auf dem Quellcode, ohne Zwischenrepräsentation, und nutzt den C-Callstack für Blöcke. Trotz der winzigen Größe schafft er es, FizzBuzz korrekt auszuführen. Der Artikel zeigt den Entwicklungsprozess, Golfing-Tricks und den finalen Code.
Es ist ziemlich schön, was wir ohne Zwischenrepräsentation erreichen können!
- jrdres
Der Code bringt mich zum Lächeln, weil er richtig fies ist. Das ist nicht wie C4, ein winziger, aber vollständiger C-Compiler, der Fehlerprüfung für seine Teilmenge durchführt. Stattdessen ist das schlimmer als Sector C, das jede Abkürzung nimmt und einfach annimmt, dass alles im Quellcode korrekt ist.
Dieses "Python" nimmt für Schlüsselwörter einfach Folgendes an:
Jedes "f" ist ein "for [x] in range[y]" (genau das, keine anderen for's).
Jedes "w" ist ein "while".
Jedes "i" ist ein "if".
Jedes "d" ist ein "def".
Jedes "p" ist ein "print(".
Fies, fies.
(Auch fies ist, dass die Code-Snippets im Artikel mehr Kommentare haben als die GitHub-Kopie der "lesbaren" Version. Man braucht den Artikel, um zu verstehen, was los ist.)
Das ist ein bisschen zu einfach für ein "Tiny Python". Wenn jemand bereit ist, ein paar K mehr an Bytes zuzulassen, würde ich mir hier wenigstens Listen und Diktate wünschen – Lisp kann das!
- teddyh
Für diejenigen, die so etwas tatsächlich in der Produktion brauchen, gibt es Snek: <https://sneklang.org/> "Snek ist eine winzige eingebettete Sprache, die auf Prozessoren mit nur wenigen kB Flash und RAM abzielt."
- marcelo-earth
Beim Lesen des Artikels kann ich nicht glauben, dass ich gerade erst von Code Golf erfahren habe. Ich bin seit über einem Jahrzehnt Programmierer.
Aber ja, erstaunliches Projekt! Ich mag, dass es von Menschen gemacht ist :)
- userbinator
Um genau zu sein, sind das 1024 Bytes C, die zu einem Binärprogramm kompilieren, das um ein Vielfaches größer ist, und das einen sehr kleinen Teil von Python implementiert.
Schleifen funktionieren, indem sie zurück springen und den Quellcode bei jeder Iteration neu parsen.
So funktioniert die DOS-.bat-Verarbeitung; ich bin nicht sicher, ob Unix-Shells dasselbe tun, da ich nie das Bedürfnis hatte, diese "Funktion" auszunutzen.
Ein anderer Kommentar hier hat C4 erwähnt, aber ein weiterer extrem dichter (und etwas größerer, da er nicht absichtlich(!) "code-gegolft" wurde) Interpreter, den du dir ansehen solltest, ist das J Incunabulum:
https://www.jsoftware.com/ioj/iojATW.htm
Allgemeiner scheint die Array-Programmierkultur diese Dichte als die Norm zu betrachten:
- stevefan1999
Aber um ehrlich zu sein, frage ich mich, was die kleinste interpretierbare und praktische Turing-vollständige VM ist? Ich würde argumentieren, dass die Implementierung eines Brainfuck, auf das wir den Python-Interpreter herunterbrechen, oder sogar so etwas wie ein Interpreter für untypisiertes Lambda-Kalkül oder SKI-Kombinatorik sehr nützlich wäre, besonders für das Hardware-Bootstrapping.
Ich spreche von Dingen wie SectorLisp https://justine.lol/sectorlisp/
- jeanmichelselli
Interessant, besonders wenn man bedenkt, dass man früher einen vollständigen BASIC-Interpreter in weniger als 32 KB ausgeliefert hat.
- shmoil
Der Autor hat mich sofort verloren.
>> Ich begann mit dem einfachsten Code, den ich mir vorstellen konnte: 1 + 2
OK, wie hast du das in 512/1024 Bytes untergebracht??? Hast du print(3 * * 1000) versucht?
- andai
Auch vom Autor:
Lass uns einen winzigen Compiler bauen