A Python interpreter squeezed into 1024 bytes of C
Making a Python interpreter in 1024 bytes
Austin Z. Henley, a professor and tool builder, takes on the challenge of writing a Python interpreter in just 1024 bytes of C code. He starts with a recursive descent parser, then adds control flow by using the C call stack for indentation-based blocks and jumping back to reparse loops. The final golfed version supports variables, arithmetic, comparisons, if/else, while and for loops, functions, and print statements—enough to run FizzBuzz. He shares the full source and the golfing tricks that made it possible.
It is quite beautiful what we can do even with no intermediate representation!
- jrdres
The code makes me smile, because it's nasty. This isn't like C4, a tiny but complete C compiler which does error checking on its subset. Instead, this is worse than Sector C, which takes every shortcut and just plain assumes everything in the source is right.
This "Python" just plain assumes for keywords:
Any "f" is a "for [x] in range[y]" (exactly that, no other for's).
Any "w" is a "while".
Any "i" is an "if".
Any "d" is a "def".
Any "p" is a "print("
Nasty, nasty.
(Also nasty is that the code snippets in the article has more comments than the github copy of the "readable" version. You need the article to understand what's going on.)
This is a just a bit too simple for a "Tiny Python". If somebody is willing to allow a few more K's of bytes, I'd love to see at least lists & dicts here--Lisp can do them!
- teddyh
For those who actually need something like this in production, there is Snek: <https://sneklang.org/> “Snek is a tiny embeddable language targeting processors with only a few kB of flash and ram.”
- marcelo-earth
Reading the article, I can't believe I just found out Code Golf is a thing. I've been a programmer for more than a decade.
But yes, amazing project! I like that it's human-made :)
- userbinator
To be precise this is 1024 bytes of C, which compiles to a binary many times larger, and implements a very tiny subset of Python.
loops work by jumping backwards and reparsing the source each iteration
This is how the DOS .bat processing works; not sure if Unix-style shells are the same, as I've never had the need to exploit that "feature".
Another comment here has mentioned C4, but another extremely dense (and slightly larger, since it wasn't actually deliberately(!) "code-golfed") interpreter you may want to look at is the J Incunabulum:
https://www.jsoftware.com/ioj/iojATW.htm
More generally, the array programming culture seems to consider this level of density the norm:
- stevefan1999
But to be honest, I wonder what is the smallest interpretable and practical Turing Complete VM? I would argue that implementing a brainfuck that we lower Python interpreter to, or even say like an interpreter untyped lambda calculus or SKI combinator would be very useful, especially for the hardware bootstrapping.
I'm talking about things like SectorLisp https://justine.lol/sectorlisp/
- jeanmichelselli
Interesting, especially when you know they used to ship a complete BASIC interpreter in less than 32 KB in the past..
- shmoil
The author lost me right away.
>> I started with the most basic code I could think of: 1 + 2
OK, how did you fit that into 512/1024 bytes??? Did you try print(3 * * 1000)?
- andai
Also by the author:
Let's make a teeny tiny compiler