At a former workplace where most stuff was done in PHP, some colleagues used whitespace very liberally. Like, indentation was just a random amount of whitespace, every line slightly different. Sometimes 2 or more spaces between keywords, etc.
After that experience Python code is like eye-bleach to me.
> did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?
Significant indentation requires a more complex lexer because it means the lexical grammar is no longer regular. The lexer can't just be a finite state machine, instead it has to maintain a stack of previous indentation levels.
But I don't think many languages have a regular lexical grammar anyway. Without significant indentation, other features still require the lexer to maintain a stack - e.g. string interpolation (Python's f-strings).
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.”
Yes, but compiling or modifying Snek from source is very challenging. I wish it was one single C file for an example base like Posix, instead of many files for many platforms plus a custom parser in Python (Lola).
One could imagine an even smaller subset interpreter. It's an interpreter for a subset of Python, consisting only of the programs that print "Hello World". Since it doesn't do any error checking, for all other programs the output is undefined. Implementing it is very simple: Just ignore the input file, and print "Hello World". As a bonus, it's an interpreter for the subset of "Hello World" programs in all other programming languages too!
(It should be noted that these are all joke esolangs. There are actual languages on the wiki that are very interesting though - I would definitely recommend you take them out!)
Yeah the amount of Python code that would work here is probably not a lot more than this specific FizzBuzz example. Lots of shortcuts taken, which I guess is understandable.
This is really cool! It's so fun to see what you can achieve and what's optional. I have seen the 'single character variable' limitation in some other minilangs before, but using the source itself as the target of function calls and loops is new to me. It does make a lot of sense but I wouldn't have thought of that.
but using the source itself as the target of function calls and loops is new to me
This was standard practice on interpreters for 8-bit microcomputers; with only a 64K total address space, creating an AST first seems immensely wasteful, so you interpret from the source directly.
I believe shells still do this when you run shell scripts; I know the DOS COMMAND.COM definitely does.
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!
I'm not actually sure about this specific project, but people are still hard at work making CPython faster. Many of them the same people as where in this project.
Because of that it wouldn’t surprise me much if that sped up some standard benchmarks, for example ones parsing lots of small json objects into dictionaries.
I would be very surprised if my silly suggestion would speed up some standard benchmarks, because even if you do insertion only you have to do a linear probe to find duplicates.
The way Python guarantees to preserve insertion order is pretty clever and doesn't really cost you much at runtime. They pretty much only added this guarantee because it was basically free to offer given the implementation choices they already wanted to make for other reasons.
Good idea. Write a python script, and then code the minimal c interpreter possible to make that specific script work, utilizing the script itself as string reference (and any other way one can manage to utilize it in the interpreter itself).
Meaning that something as simple as "w = 4" would fail? A little too nasty for my liking. Not a choice I would have made, but admire the amount of work done here and the readability of the article. And it's more human-written code than I've done in a number of months!
Just ask your preferred AI tool if it can shrink the OP's code while keeping the same functionality; I suspect it could. At this point, LLMs are probably no worse than an average human at sizecoding or targeting resource-constrained platforms in general; https://news.ycombinator.com/item?id=49226923 is a recent example of how powerful they've become.
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:
Bash lines are buffered, so modifying behind the program position doesn't really work, but you can self-append to the file to keep a script going infinitely.
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 think we would need to balance practicability and code size since they tend to be mutually exclusive. Generally speaking, code size is not an important metric to make useful code, and usefulness is usually not the main point of code golf exercises such as this one.
The exception to this is obviously embedded systems with very low amounts of resources where C and assembly are practically unrivaled.
Love the challenge, but im sorry eliminating error checking is cheating and means its not a proper self contained interpreter, because it requires a human to pre-verify and enter only correct programs.
It's not real Python. It's essentially a made-up language that resembles a subset of Python.
That said, if I was building a small ugly toy Python implementation, I would probably also not implement long integers. Or the power operator. At least not in the first iteration.
More interesting idea was to make compiler for some subset of Python bytecode. But Antigravity said this idea suxs, for some complex reasons. If the target is ATtiny, makes more sense to ask the AI translate Python to C++, which approach works amazingly well indeed.
77 comments
[ 0.26 ms ] story [ 6.4 ms ] threadAs implementer of an interpreter, did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?
Uhhh, no. Sure, it's posited by people who feel they are are forced to use it, but it's basically unlearning other syntax.
Here's a study about people with no experience. They do better with python:
https://www.researchgate.net/publication/262256894_An_Empiri...
When the scala language made whitespace optional, it was very divisive, but now it's extremely well accepted.
After that experience Python code is like eye-bleach to me.
Significant indentation requires a more complex lexer because it means the lexical grammar is no longer regular. The lexer can't just be a finite state machine, instead it has to maintain a stack of previous indentation levels.
But I don't think many languages have a regular lexical grammar anyway. Without significant indentation, other features still require the lexer to maintain a stack - e.g. string interpolation (Python's f-strings).
This is not Python, or even within three orders of magnitude of Python.
</tongue-in-cheek>
https://esolangs.org/wiki/Hello
While quines (programs that print their own source code) aren't possible in Hello, there's a version that makes it possible:
https://esolangs.org/wiki/Hello_Plus_Plus
And if you say the original isn't good enough because it can't do anything else... well, esolangs have you covered there too:
https://esolangs.org/wiki/HQ9_Plus
(It should be noted that these are all joke esolangs. There are actual languages on the wiki that are very interesting though - I would definitely recommend you take them out!)
I obviously meant "check them out" here. I was using speech recognition and it clearly misheard what I said.
I'd edit, but it's been long enough since I posted that HN isn't offering that option for this comment any more.
For instance this program works in this interpreter, but not in python:
https://justine.lol/sectorlisp/
https://github.com/xorvoid/sectorc
Edit: I wonder if sectorC could compile python1024
This was standard practice on interpreters for 8-bit microcomputers; with only a 64K total address space, creating an AST first seems immensely wasteful, so you interpret from the source directly.
I believe shells still do this when you run shell scripts; I know the DOS COMMAND.COM definitely does.
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!
(Slightly less silly: the folks at https://github.com/faster-cpython are doing great work, too.)
Because of that it wouldn’t surprise me much if that sped up some standard benchmarks, for example ones parsing lots of small json objects into dictionaries.
The way Python guarantees to preserve insertion order is pretty clever and doesn't really cost you much at runtime. They pretty much only added this guarantee because it was basically free to offer given the implementation choices they already wanted to make for other reasons.
Clearly supporting multiple functions starting with 'p' would be overengineering.
Meaning that something as simple as "w = 4" would fail? A little too nasty for my liking. Not a choice I would have made, but admire the amount of work done here and the readability of the article. And it's more human-written code than I've done in a number of months!
But yes, amazing project! I like that it's human-made :)
https://beta.dwitter.net
Also https://github.com/nanochess
And then if you really want to go large
https://phoboslab.org/log/2021/09/q1k3-making-of
I still have a soft spot for https://www.pouet.net/prod.php?which=1221
Probably curiosity.
If there's an AI version of code golfing, I'd be curious to see it. Maybe they golf worse or much better than us meat bags.
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:
https://news.ycombinator.com/item?id=45800777
https://github.com/AZHenley/python1024/blob/main/python1024_...
Well done!
Let's make a teeny tiny compiler
https://news.ycombinator.com/item?id=36102460
I appreciate .kkrieger much more than this monstrosity
1. Choose a small fragment of the language
2. Adapt an existing interpreter
3. Use a tool to shorten the code, 'minify'
I'm talking about things like SectorLisp https://justine.lol/sectorlisp/
The exception to this is obviously embedded systems with very low amounts of resources where C and assembly are practically unrivaled.
>> 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)'?
That said, if I was building a small ugly toy Python implementation, I would probably also not implement long integers. Or the power operator. At least not in the first iteration.
Like a psychopath.
/s