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!
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.
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!
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).
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.
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.
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.
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.
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!
SectorLISP makes an important question in its implementation: how much can strip down Lisp before stops being Lisp. Same is not done for submitted interpreter. So, although SectorLISP goal is to be a Lisp-reduced-to-its-essentials implementation, the Python-1024 goal seems to be imitating Python in most minimal code possible.
Or you just forbid mixing spaces and tabs in the same indentation sequence, the way most whitespace-sensitive languages seem to end up doing. Or you make a slightly more reasonable rule: spaces may follow tabs, but no tabs may follow a space. That's at least unambiguous.
Oh, that's really elegant! I've got a whitespace sensitive language of my own, and I think I'll change it to use that rule! Thanks!
(Until now, I went with the standard approach: Remember the leading whitespace of the previous line. Then compare with the new line's leading whitespace: If they are the same, then no change in indentation. If the old one is a prefix of the new one, it's an indent. If the new one is a prefix of the old one, it's a dedent. If neither, it's an error)
That seems like a decent way to handle the mixed-spaces-and-tabs scenario, even between lines: one line starts with `<tab><tab>`, the next line `<tab><tab><sp><sp><sp><sp>`, that's an indent. (Probably someone who likes 4-space indents and 8-space tab characters). Follow that up with `<sp>*12` and that looks like the same indent to someone who uses 4-space tabs, but not the same indent to someone who uses 8-space tabs.
So your proposed prefix-matching rule would correctly flag that scenario, forcing people stop and figure it out.
EDIT to add this P.S.: Actually, my "spaces may follow a tab but tabs may not follow a space" rule, while elegant, is incomplete. Your prefix-matching rule is actually necessary in order to deal with the "two tabs on one line, twelve spaces on the next line" situation. That would be legal under the "spaces may follow a tab but tabs may not follow a space" rule, but it's ambiguous whether that's an indent or a dedent. If tabs mean eight spaces then it's going from 16 to 12, a dedent; if tabs mean four spaces then it's going from 8 to 12, an indent.
But it also feels arbitrary and annoyingly restrictive. On top of that there are at least 25 whitespace codepoints in UTF. Should your language really be opinionated about when, where, and in what order (for example) the "mongolian vowel separator" appears?
I mean, obviously that one should only appear within Mongolian text and not within indentation.
To state explicitly what should be implicitly obvious, there is no valid reason (that I'm aware of, I welcome any non-facetious correction) to use any character except U+0009 and U+0020 within indentation. Horizontal Record Separator? Zero-width joiner? Language-specific whitespace characters like your example? All make sense within human text (well, maybe not HRS), but in programming, they should be eschewed in favor of the characters that can be typed in every single keyboard layout in the world. Even languages that don't put spaces between words, such as Thai, still put spaces between sentences (or comma phrases) and therefore keep the space bar in their keyboard layout.
And since mixing tabs and spaces (even between lines, where some lines are tab-indented and some are space-indented) creates problems for whitespace-sensitive language, there's a reason why every whitespace-sensitive language I'm aware of has tended to either outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations, which are usually not available to the validation code running in CI or on other people's machines).
> To state explicitly what should be implicitly obvious, there is no valid reason ...
There doesn't need to be an articulable reason. Or rather there's generally no expectation that a central authority will be able to reliably enumerate such. Everything should default to being permitted and only ever be restricted for good reason.
But since you asked. U+2003 for example carries formatting information. Maybe an editor could be written (or even already exists) that would find that useful. Who is any third party to dictate that?
U+00A0 similarly communicates information about the desired formatting and I can see no reason it would be unreasonable for someone to use it nor why its use should pose a technical challenge to a compiler.
> creates problems for whitespace-sensitive langauge
Does it? That seems like an invented problem to me. You have a running prefix composed of arbitrary whitespace characters. Any change in that prefix is a change in the level of indentation. You can add or remove arbitrary amounts from the end of the prefix. In the event you remove from it the result must exactly match the previous stack level. What's so complicated about this?
> outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations ...
Did you mix up your code points there? It's space that's ambiguous, not tab.
Regardless I think that a compiler worrying about the specifics of text editors or other tooling would be backward information flow and a massive abstraction violation. Semantic meaning is entirely dictated by the compiler, not the other way around. There's no convincing reason (IMO) to impose restrictions that aren't technically necessary or to otherwise needlessly employ solutions that would reduce generalization.
> Did you mix up your code points there? It's space that's ambiguous, not tab.
Space is always the same width, but tab means a variable number of spaces (usually either 4 or 8, but I've seen 3 before) depending on people's editor configuration.
What makes you say that the space character, U+0020, is ambiguous?
A single tab always indicates (AFAIK, in common usage) a single level of indentation. Whereas depending on editor configuration a single level of indentation could be represented by any number of spaces - commonly somewhere between 4 and 8, but who can say?
Tab never "means" any number of spaces. How it gets displayed varies but the meaning (of any character, not just tab) can only ever be determined by usage, not display choices (at least for any sane way of doing things). Otherwise what would you make of escape sequences or binary files? Or constructs such as a nonbreaking space?
What business does a compiler have worrying about display width? As I said earlier worrying about the specifics of the editor or other tooling would be backwards information flow and a massive abstraction violation. What if I choose to program in a variable width font? (For the record writing that left me feeling disgusted.)
Got it. You're looking at the problem from the other direction. Yes, tabs are unambiguous if they're the only thing used for indentation. It's when some people use tabs and others use spaces that ambiguity arises.
But there are other cases where the variable-width nature of tabs can create ambiguity all by itself. Take this example from R7RS small:
But to everyone else using a different editor, where the convention is "the tab character just advances to the next multiple of T" (where T is usually 4 or 8), then the second and third lines won't be correctly aligned. And then instead of being able to use the indentation as a visual reference and ignore the parentheses, those people will have to revert to counting parentheses in order to figure out what S-expression each form is part of. Granted, in this simple example that's not hard, but imagine that `cond` nested deep inside a larger expression including a `call/cc` and a `let` or two, rather than being at the top level where it's easy to read.
Here, the ambiguity is because the tab character needs to have a width of six characters in order to align with the text `(cond `. If that had been an `(if ` with just two forms (omitting the `(else 'equal)` case) then the tab would have needed to have a width of four characters. A smart editor that reads the Lisp code and can interpret `<tab>` as meaning "indent this form to align with the form on the line above", but any context that isn't syntax-aware, such as a git diff, will not align those tabs correctly.
Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.
> It's when some people use tabs and others use spaces that ambiguity arises.
I don't think so? Assuming we're talking about significant whitespace here and assuming we're maintaining a consistent prefix within a given block then AFAICT there is never any ambiguity. To argue otherwise it seems to me that one of two things must be true.
It could be that spaces are equally ambiguous because in theory you can use any number of either of them for a single level of indentation. While that isn't syntactically ambiguous I suppose it might bother some people.
Or it could be that the compiler is concerning itself with how different editors might choose to display a given line of text in different instances which is (IMO) fundamentally broken and a path down which only madness lies (and anyway suffers from the variable width font conundrum I pointed out earlier).
If you have any counterexamples I'd be interested to see them.
> But to everyone else using a different editor, where the convention is "the tab character just advances to the next multiple of T" (where T is usually 4 or 8), then the second and third lines won't be correctly aligned.
No, you've got a misconception here. An editor should never go out of its way to align that. That would be broken by design. Tabs are never for alignment. Never. Notice that syntactically no new scope has been introduced. So you are still at the same indentation level as the `cond` and you are aligning (thus you _must_ use spaces) a list of expressions that has been split one per line.
I think the entire controversy arises because people (incorrectly IMO) get the idea in their heads that a tab character has some fixed width. It does not. In the context of source code it communicates the concept of indentation, never anything more. It's entirely up to the editor how exactly to display indented code.
> Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.
Right, but that is in my view misguided and anyhow is not of any concern to the compiler. Recall that the original topic and my contention had to do with the possibility of syntactic ambiguity in a language with significant whitespace, not with formatting inconsistencies between different programmers.
The counterexample I've personally seen is multiple people editing the same file with different editors. The first person has his editor configured to indent with tab characters, and he writes Python code like this:
Now a second guy edits the file. His editor is configured to indent with spaces. He adds `do_something_else()`, and doesn't notice that the code block no longer has a consistent prefix:
Notice that because I've used five characters to type `<tab>`, it is already visually obvious that this is incorrectly indented. But that wasn't obvious to guy number two, because this is what he saw on his screen:
def example():
if True:
do_something()
do_something_else()
The compiler itself isn't per se concerning itself with how different editors have chosen to display tab characters. But in practice, it has to decide "is the do_something_else() line part of the `if True` block, or not?" And so it has to have some opinion on tab characters. Here, that opinion will be "Inconsistent mixing of tabs and spaces in same file, impossible to know programmer intent, refusing to guess; raise TabError exception here".
The use of .editorconfig files should, in theory, solve this. But just yesterday I had another file, thankfully one where whitespace was not significant. The .editorconfig file said "Indent with tab characters", so my editor, when I opened a new line, indented it with tab characters. But the file was actually indented with spaces, and nobody had fixed the .editorconfig file to say "indent with tab characters... except for this file which is indented with spaces".
Editor misconfiguration in both cases. Not strictly the couterexamples you were asking about. But the Python example, although made up, is reflective of actual situations I've seen. People with different editors editing a file, not paying attention to whitespace, and ending up with ambiguity where the width of a tab character would actually make a difference to whether a line visually appears lined up with its indentation block or a different one.
Tabs are great for indentation in theory. In practice, I've personally seen more pain than gain from files that used them.
Surely tabs are only ambiguous if one considers the point of indentation to be to align things visually in relation to each other, as opposed to just being, y'know, indented.
Besides, I'm sure many people would look at your Scheme snippet and argue that it's not really about indentation as much as alignment of the subforms, because in a Lisp those two things are basically equivalent, and that the distinction between indentation and alignment is mostly a thing for the curly-brace or otherwise ALGOL-esque languages like Pascal or in this case Python. And in those cases the use of "tabs for indentation, spaces for alignment" is fairly popular although I don't frankly know if many editors actually support that.
I do however think that this whole discussion of spaces Vs tabs is pretty asinine and mostly just stems from people just wanting to align code text visually across lines. It's the same way people insist on monospaced fonts even though one could easily make the argument that proportional fonts are easier to read. Oh well, even I'm not _that_ deprived.
> the use of "tabs for indentation, spaces for alignment" is fairly popular although I don't frankly know if many editors actually support that.
It all works swimmingly until you introduce a nested scope (indentation, tabs) in the middle of an aligned scope (spaces). At that point it still works in the sense that everything is correctly aligned however depending on the editor the tabs might not all have the same width if you aren't able to disable tabstop.
So it isn't generally recommended for lisps in practice (because most common editors will correctly align any given block but when considered in whole the formatting will be inconsistent) but poses near zero problems for most c like languages. (If you're determined you can manage to create problems in a c like by nesting an anonymous lambda within an aligned list of statements or similar such shenanigans. However pretending that python or c++ is a lisp is generally frowned upon so in practice all tabs can be expected to appear to the left of any spaces.)
The other problem I've personally seen with "tabs for indentation, spaces for alignment" is when your editor destroys your tab-space mix when it adjusts the indentation. I've personally seen an editor, I believe VS Code but I don't remember for certain (EDIT: on second thought it was probably Visual Studio, as my memory is placing me in an office I worked in around 2010 or 2011, before VS Code was created), turn a `<tab><tab><sp><sp>...<sp><sp>` line into `<tab><tab><tab><tab>...<tab>` when I intended or dedented it as part of a code block. I.e., I added or removed an `if:`, highlighted a section of code, and pressed the Tab or Shift-Tab shortcuts. And boom, that section of code was no longer in correct "tabs for indentation, spaces for alignment" syntax: the editor had converted a certain number of alignment spaces into tabs.
That was one of the moments that made me move away from tab characters in all circumstances. Because the only way to prevent that sort of thing from happening would be either to fix the editor bug (which I don't have time to do), or to turn on visible whitespace and pay close attention to whitespace every time I make an indentation change, knowing that the editor will sometimes do the wrong thing. I don't want to have to pay close attention to whitespace, and the only way I've found not to have to pay close attention is to either never align things at all, or never use tab characters. Tabs for indentation and spaces for alignment works great in theory, but in practice I have found I can't trust major editors to handle it right.
Truly, indentation is the moveable feast. Even on ancient typewriters, you could adjust your tabs depending on what you are doing. And people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors.
> What business does a compiler have worrying about display width?
The business of the compiler is to insure that code that it deems acceptable is not ambiguous to different users. Since people can set their own tab spacing, display of tabs is, in an indentation-sensitive language, inherently ambiguous.
> What if I choose to program in a variable width font?
As long as the spacing of any prepended whitespace doesn't arbitrarily change depending on the phase of the moon, the compiler shouldn't (and Python doesn't) give a rat's ass about your display preferences.
The only important thing here is that the location of the left margin on every line is meaningful, both to the compiler, and to any viewers of your code.
> people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors.
Not for code, no. People will do that for spaces. For tabs it's a 1:1 correspondence with indentation level with any visual adjustments done by the editor.
Reading between the lines I suspect you are operating with the flawed idea of using tabs for alignment. One must never use tabs for alignment purposes because they very explicitly do not have a fixed width. (They have a consistent width within a document at any given point in time but it is entirely arbitrary and can change at any time.)
> insure that code that it deems acceptable is not ambiguous to different users ... display of tabs
A compiler never has any control over display. It must ensure no _semantic_ ambiguity. And indeed there isn't any to be found here. Even in python where you can introduce an arbitrary amount of whitespace when going up a level of indentation there is never any semantic ambiguity.
In short you are confused about the division of labor within the stack of abstractions.
> The only important thing here is that the location of the left margin on every line is meaningful, both to the compiler, and to any viewers of your code.
I'd dispute that the compiler needs to care about where your editor places the left margin. However rather than argue about bizarre hypothetical text editors that do unhinged things when displaying whitespace for no apparent reason, I'll instead observe that it seems to follow from what you said that you actually agree with me. As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.
How so? In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code? Let alone using esoteric Unicode whitespace characters for indentation. I think it is perfectly reasonable for the language to make the restriction that indentation must be either all tabs, tabs followed by spaces, or all spaces.
> In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code?
Writing a lisp in an editor that doesn't do boneheaded things with tabs? That's the only one I've personally run into but lack of imagination is hardly a good excuse to implement arbitrary restrictions.
> Let alone using esoteric Unicode whitespace characters for indentation.
How do you know what's esoteric in other countries? I certainly don't. I'm not an expert in linguistics but I'm sure that people everywhere in the world write computer programs at this point.
> I think it is perfectly reasonable ...
Without any concrete justification? Why would entirely artificial restrictions ever be seen as reasonable?
What "boneheaded things with tabs" are you referring to? The picture I'm piecing together from your comments suggests that you may use tab characters in a different way than most people seem to, so I'd quite like a further explanation of how you use tab characters and how you expect an editor to handle them.
> you may use tab characters in a different way than most people seem to
As far as I'm aware there are three primary and entirely independent uses for tabs. Indentation, field separation, and typesetting. When it comes to typesetting and also to display of fields with a narrow maximum width the concept of a tabstop is useful.
Boneheaded things with tabs was in reference to code editors (where tabs are more or less exclusively used for indentation) most often failing to provide the ability to disable tabstop. In practice this generally hasn't been a point of friction because until fairly recently the most popular languages (ie C & co) didn't support constructs that would lead to adding any indentation outside of the prefix of a line.
Agreed... but see my Lisp example in https://news.ycombinator.com/item?id=49593406 for a place where tabs end up unavoidably ambiguous. Because in that `cond` example the tabs look like they're used for indentation, but they're actually being used for alignment, something that falls more under typesetting than under indentation. A smart editor that has read the Lisp code (note that I'm using "read" in its Lisp meaning, i.e. "parsed into a syntax tree") can make those tab characters correctly align the forms the way you'd want them to be aligned for maximum understanding... but really, you would want space characters, not tab characters, in that context.
So even though in most cases those three uses for tabs are independent, in some languages they get muddled. F# is another language where you may want to align text on line two with the middle of line one, e.g. if you write
let person = { FirstName = "Bill"
LastName = "Gates" }
(Those two links point to different anchors in the same document, BTW: the HN link shortening is going to make them look identical until you hover over them).
The cond example commits a sin (see my other reply), in the F# example tabs (were they permitted) would introduce no ambiguity if used solely to communicate indentation, and the only change I would make to the F# example were I formatting it myself would be to also align the `=` characters. Actually that supposedly bad style is more or less exactly how I write nix expressions (as a matter of practicality I do not use tabs when writing those FWIW).
I agree that the cond example is committing the sin of trying to align with tabs. I wrote it because I had misunderstood something you were saying. But also, I've personally seen situations like this. I was working in a team whose indentation convention was "one tab character per indent level", and I had written some C# code like this:
var result = someObject.SomeMethod(param1, param2,
param3, param4);
And then to my horror I noticed that the editor (earlier I said it was VS Code, but thinking back I think it was actually Visual Studio) had produced this monstrosity:
var result = someObject.SomeMethod(param1, param2,
<tab><tab><tab><tab><tab><tab><tab>param3, param4);
(Actual number of tabs was different, of course, and I believe it was followed at the end by a space or two, whereas my example happened to line up without needing an extra space character).
I know not to do that. The editor did it anyway, and if I hadn't been paying close attention to whitespace I might not have caught it.
The editor could have been smart enough to parse the code into an AST, notice that param3 and param4 were part of a parameter group, and said "I will use tab characters equal to the indentation of `var result`, then spaces thereafter". It didn't. I had to edit the call to look like this:
var result = someObject.SomeMethod(
param1, param2, param3, param4
);
And then I was safe from the editor trying to align things with tab characters.
If my memory is right about which office I was working in when I saw the editor do that to my code, then it was more than a decade ago, probably around 2010 or 2011. It's possible that the modern version of that editor has improved its handling, and would have correctly aligned param3 with spaces. I haven't checked recently. Maybe at some point I will, and report my findings.
Right, pointers to strings but yeah. Essentially the whitespace count specifies the stack depth at which a line is to be executed. A decrease in stack depth means all superior levels are terminated.
> 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 modern languages have a regular lexical grammar anyway. Without significant indentation, some other features still require the lexer to maintain a stack - e.g. string interpolation (Python's f-strings).
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.
I meant users of languages ( application programmers) as opposed to compiler programmers, not python programmers specifically, so I'm including devs that use other languages and see in python a tool that they would consume.
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.
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!
It looks very much like some techniques used when minifying JavaScript.
As they say in TDD, write a test, then write the simplest code that will make it pass.
Clearly supporting multiple functions starting with 'p' would be overengineering.
By that standard, this is totally over-engineered. Just hardcode it.
If you are willing to sacrifice performance, you can implement dicts via linear lookup in much less code than a proper hash table.
Because Python dicts guarantee iteration order is the same as insertion order (https://docs.python.org/3.7/library/stdtypes.html#typesmappi...) Python dicts aren’t just proper hash tables.
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.
It’s Python, you’ve already sacrificed performance, what a little bit more?
That's the spirit!
(Slightly less silly: the folks at https://github.com/faster-cpython are doing great work, too.)
Are they still? I thought this project was no longer really active.
> Any "w" is a "while"
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!
Reminds me of the good 'ol Apple II BASIC. You can name your variables whatever you want, but only the first two letters matter.
Two letters is luxury, when most BASIC interpreters in those days only recognised 1-letter variables.
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).
Or Forth.
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/
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 :)
The quintessential example is donut.c. I was amazed when I first came across it.
https://www.a1k0n.net/2006/09/15/obfuscated-c-donut.html
> This was my first attempt at obfuscated C and I feel it's pretty amateurish
I love feelings of inadequacy at 11:07pm on a Sunday.
Here's the judges' remarks and author commentary on the second edition of this from the 2006 results: https://www.ioccc.org/2006/sloane/index.html
This one is my favorite:
https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
Always fun to see this pop up years later. (Damn, 20 years now)
Thanks, this makes me happy.
Absolute legend
> it’s worked on every system I’ve tried so far though
Still my favorite part of the whole thing. Classic moment of “who among us hasn’t doesn’t this?” lol
Get thee to
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
This is my favorite : https://www.cise.ufl.edu/~manuel/obfuscate/pi.c
look at https://codegolf.stackexchange.com
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:
https://news.ycombinator.com/item?id=45800777
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.
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.
I was very disappointed that this is “interpreting” some tiny made up language.
This is not Python, or even within three orders of magnitude of Python.
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.
It’s true, the title should have said “Python-like”
TBF the fizzbuzz code works just fine in CPython.
Indeed, for some code, CPython and this interpreter produce identical output. I gave it an upboat.
I like python subset. However, many don't see it that way.
You're right, mathematically it's undeniably true. However...
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!
</tongue-in-cheek>
It's not a subset of python.
For instance this program works in this interpreter, but not in python:
Also by the author:
Let's make a teeny tiny compiler
https://news.ycombinator.com/item?id=36102460
This seems to be in the same spirit as Justine Tunney's SectorLISP. Very cool.
https://justine.lol/sectorlisp/
SectorLISP makes an important question in its implementation: how much can strip down Lisp before stops being Lisp. Same is not done for submitted interpreter. So, although SectorLISP goal is to be a Lisp-reduced-to-its-essentials implementation, the Python-1024 goal seems to be imitating Python in most minimal code possible.
Or sectorC
https://github.com/xorvoid/sectorc
Edit: I wonder if sectorC could compile python1024
Good use of free will and well-written. Very nice walkthrough austin!
The condensed version is impressive to be sure, but I'm an even bigger fan of the readable version:
https://github.com/AZHenley/python1024/blob/main/python1024_...
Well done!
I hate when they measure the size of source code instead of the size of a binary.
I appreciate .kkrieger much more than this monstrosity
well written, looks cool ngl
A lot of criticism of python often mentions the whitespace as lexical scope tokens, and that criticism is usually posited by users of the language.
As implementer of an interpreter, did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?
And, there are multiple white space symbols!
<space><space><tab><space>
is different than
<space><tab><space><space>
So you also have to track the actual sequence of counts of white space used for each level, rather than just a simple count.
Or you just forbid mixing spaces and tabs in the same indentation sequence, the way most whitespace-sensitive languages seem to end up doing. Or you make a slightly more reasonable rule: spaces may follow tabs, but no tabs may follow a space. That's at least unambiguous.
Oh, that's really elegant! I've got a whitespace sensitive language of my own, and I think I'll change it to use that rule! Thanks!
(Until now, I went with the standard approach: Remember the leading whitespace of the previous line. Then compare with the new line's leading whitespace: If they are the same, then no change in indentation. If the old one is a prefix of the new one, it's an indent. If the new one is a prefix of the old one, it's a dedent. If neither, it's an error)
That seems like a decent way to handle the mixed-spaces-and-tabs scenario, even between lines: one line starts with `<tab><tab>`, the next line `<tab><tab><sp><sp><sp><sp>`, that's an indent. (Probably someone who likes 4-space indents and 8-space tab characters). Follow that up with `<sp>*12` and that looks like the same indent to someone who uses 4-space tabs, but not the same indent to someone who uses 8-space tabs.
So your proposed prefix-matching rule would correctly flag that scenario, forcing people stop and figure it out.
EDIT to add this P.S.: Actually, my "spaces may follow a tab but tabs may not follow a space" rule, while elegant, is incomplete. Your prefix-matching rule is actually necessary in order to deal with the "two tabs on one line, twelve spaces on the next line" situation. That would be legal under the "spaces may follow a tab but tabs may not follow a space" rule, but it's ambiguous whether that's an indent or a dedent. If tabs mean eight spaces then it's going from 16 to 12, a dedent; if tabs mean four spaces then it's going from 8 to 12, an indent.
But it also feels arbitrary and annoyingly restrictive. On top of that there are at least 25 whitespace codepoints in UTF. Should your language really be opinionated about when, where, and in what order (for example) the "mongolian vowel separator" appears?
I mean, obviously that one should only appear within Mongolian text and not within indentation.
To state explicitly what should be implicitly obvious, there is no valid reason (that I'm aware of, I welcome any non-facetious correction) to use any character except U+0009 and U+0020 within indentation. Horizontal Record Separator? Zero-width joiner? Language-specific whitespace characters like your example? All make sense within human text (well, maybe not HRS), but in programming, they should be eschewed in favor of the characters that can be typed in every single keyboard layout in the world. Even languages that don't put spaces between words, such as Thai, still put spaces between sentences (or comma phrases) and therefore keep the space bar in their keyboard layout.
And since mixing tabs and spaces (even between lines, where some lines are tab-indented and some are space-indented) creates problems for whitespace-sensitive language, there's a reason why every whitespace-sensitive language I'm aware of has tended to either outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations, which are usually not available to the validation code running in CI or on other people's machines).
> To state explicitly what should be implicitly obvious, there is no valid reason ...
There doesn't need to be an articulable reason. Or rather there's generally no expectation that a central authority will be able to reliably enumerate such. Everything should default to being permitted and only ever be restricted for good reason.
But since you asked. U+2003 for example carries formatting information. Maybe an editor could be written (or even already exists) that would find that useful. Who is any third party to dictate that?
U+00A0 similarly communicates information about the desired formatting and I can see no reason it would be unreasonable for someone to use it nor why its use should pose a technical challenge to a compiler.
> creates problems for whitespace-sensitive langauge
Does it? That seems like an invented problem to me. You have a running prefix composed of arbitrary whitespace characters. Any change in that prefix is a change in the level of indentation. You can add or remove arbitrary amounts from the end of the prefix. In the event you remove from it the result must exactly match the previous stack level. What's so complicated about this?
> outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations ...
Did you mix up your code points there? It's space that's ambiguous, not tab.
Regardless I think that a compiler worrying about the specifics of text editors or other tooling would be backward information flow and a massive abstraction violation. Semantic meaning is entirely dictated by the compiler, not the other way around. There's no convincing reason (IMO) to impose restrictions that aren't technically necessary or to otherwise needlessly employ solutions that would reduce generalization.
> Did you mix up your code points there? It's space that's ambiguous, not tab.
Space is always the same width, but tab means a variable number of spaces (usually either 4 or 8, but I've seen 3 before) depending on people's editor configuration.
What makes you say that the space character, U+0020, is ambiguous?
A single tab always indicates (AFAIK, in common usage) a single level of indentation. Whereas depending on editor configuration a single level of indentation could be represented by any number of spaces - commonly somewhere between 4 and 8, but who can say?
Tab never "means" any number of spaces. How it gets displayed varies but the meaning (of any character, not just tab) can only ever be determined by usage, not display choices (at least for any sane way of doing things). Otherwise what would you make of escape sequences or binary files? Or constructs such as a nonbreaking space?
What business does a compiler have worrying about display width? As I said earlier worrying about the specifics of the editor or other tooling would be backwards information flow and a massive abstraction violation. What if I choose to program in a variable width font? (For the record writing that left me feeling disgusted.)
Got it. You're looking at the problem from the other direction. Yes, tabs are unambiguous if they're the only thing used for indentation. It's when some people use tabs and others use spaces that ambiguity arises.
But there are other cases where the variable-width nature of tabs can create ambiguity all by itself. Take this example from R7RS small:
If you write it like this, a smart editor (e.g., Emacs) would probably be able to do the right thing and line up the forms that follow the `cond`: But to everyone else using a different editor, where the convention is "the tab character just advances to the next multiple of T" (where T is usually 4 or 8), then the second and third lines won't be correctly aligned. And then instead of being able to use the indentation as a visual reference and ignore the parentheses, those people will have to revert to counting parentheses in order to figure out what S-expression each form is part of. Granted, in this simple example that's not hard, but imagine that `cond` nested deep inside a larger expression including a `call/cc` and a `let` or two, rather than being at the top level where it's easy to read.Here, the ambiguity is because the tab character needs to have a width of six characters in order to align with the text `(cond `. If that had been an `(if ` with just two forms (omitting the `(else 'equal)` case) then the tab would have needed to have a width of four characters. A smart editor that reads the Lisp code and can interpret `<tab>` as meaning "indent this form to align with the form on the line above", but any context that isn't syntax-aware, such as a git diff, will not align those tabs correctly.
Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.
> It's when some people use tabs and others use spaces that ambiguity arises.
I don't think so? Assuming we're talking about significant whitespace here and assuming we're maintaining a consistent prefix within a given block then AFAICT there is never any ambiguity. To argue otherwise it seems to me that one of two things must be true.
It could be that spaces are equally ambiguous because in theory you can use any number of either of them for a single level of indentation. While that isn't syntactically ambiguous I suppose it might bother some people.
Or it could be that the compiler is concerning itself with how different editors might choose to display a given line of text in different instances which is (IMO) fundamentally broken and a path down which only madness lies (and anyway suffers from the variable width font conundrum I pointed out earlier).
If you have any counterexamples I'd be interested to see them.
> But to everyone else using a different editor, where the convention is "the tab character just advances to the next multiple of T" (where T is usually 4 or 8), then the second and third lines won't be correctly aligned.
No, you've got a misconception here. An editor should never go out of its way to align that. That would be broken by design. Tabs are never for alignment. Never. Notice that syntactically no new scope has been introduced. So you are still at the same indentation level as the `cond` and you are aligning (thus you _must_ use spaces) a list of expressions that has been split one per line.
I think the entire controversy arises because people (incorrectly IMO) get the idea in their heads that a tab character has some fixed width. It does not. In the context of source code it communicates the concept of indentation, never anything more. It's entirely up to the editor how exactly to display indented code.
> Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.
Right, but that is in my view misguided and anyhow is not of any concern to the compiler. Recall that the original topic and my contention had to do with the possibility of syntactic ambiguity in a language with significant whitespace, not with formatting inconsistencies between different programmers.
The counterexample I've personally seen is multiple people editing the same file with different editors. The first person has his editor configured to indent with tab characters, and he writes Python code like this:
Now a second guy edits the file. His editor is configured to indent with spaces. He adds `do_something_else()`, and doesn't notice that the code block no longer has a consistent prefix: Notice that because I've used five characters to type `<tab>`, it is already visually obvious that this is incorrectly indented. But that wasn't obvious to guy number two, because this is what he saw on his screen: The compiler itself isn't per se concerning itself with how different editors have chosen to display tab characters. But in practice, it has to decide "is the do_something_else() line part of the `if True` block, or not?" And so it has to have some opinion on tab characters. Here, that opinion will be "Inconsistent mixing of tabs and spaces in same file, impossible to know programmer intent, refusing to guess; raise TabError exception here".The use of .editorconfig files should, in theory, solve this. But just yesterday I had another file, thankfully one where whitespace was not significant. The .editorconfig file said "Indent with tab characters", so my editor, when I opened a new line, indented it with tab characters. But the file was actually indented with spaces, and nobody had fixed the .editorconfig file to say "indent with tab characters... except for this file which is indented with spaces".
Editor misconfiguration in both cases. Not strictly the couterexamples you were asking about. But the Python example, although made up, is reflective of actual situations I've seen. People with different editors editing a file, not paying attention to whitespace, and ending up with ambiguity where the width of a tab character would actually make a difference to whether a line visually appears lined up with its indentation block or a different one.
Tabs are great for indentation in theory. In practice, I've personally seen more pain than gain from files that used them.
Surely tabs are only ambiguous if one considers the point of indentation to be to align things visually in relation to each other, as opposed to just being, y'know, indented.
Besides, I'm sure many people would look at your Scheme snippet and argue that it's not really about indentation as much as alignment of the subforms, because in a Lisp those two things are basically equivalent, and that the distinction between indentation and alignment is mostly a thing for the curly-brace or otherwise ALGOL-esque languages like Pascal or in this case Python. And in those cases the use of "tabs for indentation, spaces for alignment" is fairly popular although I don't frankly know if many editors actually support that.
I do however think that this whole discussion of spaces Vs tabs is pretty asinine and mostly just stems from people just wanting to align code text visually across lines. It's the same way people insist on monospaced fonts even though one could easily make the argument that proportional fonts are easier to read. Oh well, even I'm not _that_ deprived.
> the use of "tabs for indentation, spaces for alignment" is fairly popular although I don't frankly know if many editors actually support that.
It all works swimmingly until you introduce a nested scope (indentation, tabs) in the middle of an aligned scope (spaces). At that point it still works in the sense that everything is correctly aligned however depending on the editor the tabs might not all have the same width if you aren't able to disable tabstop.
So it isn't generally recommended for lisps in practice (because most common editors will correctly align any given block but when considered in whole the formatting will be inconsistent) but poses near zero problems for most c like languages. (If you're determined you can manage to create problems in a c like by nesting an anonymous lambda within an aligned list of statements or similar such shenanigans. However pretending that python or c++ is a lisp is generally frowned upon so in practice all tabs can be expected to appear to the left of any spaces.)
The other problem I've personally seen with "tabs for indentation, spaces for alignment" is when your editor destroys your tab-space mix when it adjusts the indentation. I've personally seen an editor, I believe VS Code but I don't remember for certain (EDIT: on second thought it was probably Visual Studio, as my memory is placing me in an office I worked in around 2010 or 2011, before VS Code was created), turn a `<tab><tab><sp><sp>...<sp><sp>` line into `<tab><tab><tab><tab>...<tab>` when I intended or dedented it as part of a code block. I.e., I added or removed an `if:`, highlighted a section of code, and pressed the Tab or Shift-Tab shortcuts. And boom, that section of code was no longer in correct "tabs for indentation, spaces for alignment" syntax: the editor had converted a certain number of alignment spaces into tabs.
That was one of the moments that made me move away from tab characters in all circumstances. Because the only way to prevent that sort of thing from happening would be either to fix the editor bug (which I don't have time to do), or to turn on visible whitespace and pay close attention to whitespace every time I make an indentation change, knowing that the editor will sometimes do the wrong thing. I don't want to have to pay close attention to whitespace, and the only way I've found not to have to pay close attention is to either never align things at all, or never use tab characters. Tabs for indentation and spaces for alignment works great in theory, but in practice I have found I can't trust major editors to handle it right.
Truly, indentation is the moveable feast. Even on ancient typewriters, you could adjust your tabs depending on what you are doing. And people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors.
> What business does a compiler have worrying about display width?
The business of the compiler is to insure that code that it deems acceptable is not ambiguous to different users. Since people can set their own tab spacing, display of tabs is, in an indentation-sensitive language, inherently ambiguous.
> What if I choose to program in a variable width font?
As long as the spacing of any prepended whitespace doesn't arbitrarily change depending on the phase of the moon, the compiler shouldn't (and Python doesn't) give a rat's ass about your display preferences.
The only important thing here is that the location of the left margin on every line is meaningful, both to the compiler, and to any viewers of your code.
> people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors.
Not for code, no. People will do that for spaces. For tabs it's a 1:1 correspondence with indentation level with any visual adjustments done by the editor.
Reading between the lines I suspect you are operating with the flawed idea of using tabs for alignment. One must never use tabs for alignment purposes because they very explicitly do not have a fixed width. (They have a consistent width within a document at any given point in time but it is entirely arbitrary and can change at any time.)
> insure that code that it deems acceptable is not ambiguous to different users ... display of tabs
A compiler never has any control over display. It must ensure no _semantic_ ambiguity. And indeed there isn't any to be found here. Even in python where you can introduce an arbitrary amount of whitespace when going up a level of indentation there is never any semantic ambiguity.
In short you are confused about the division of labor within the stack of abstractions.
> The only important thing here is that the location of the left margin on every line is meaningful, both to the compiler, and to any viewers of your code.
I'd dispute that the compiler needs to care about where your editor places the left margin. However rather than argue about bizarre hypothetical text editors that do unhinged things when displaying whitespace for no apparent reason, I'll instead observe that it seems to follow from what you said that you actually agree with me. As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.
> and annoyingly restrictive
How so? In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code? Let alone using esoteric Unicode whitespace characters for indentation. I think it is perfectly reasonable for the language to make the restriction that indentation must be either all tabs, tabs followed by spaces, or all spaces.
> In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code?
Writing a lisp in an editor that doesn't do boneheaded things with tabs? That's the only one I've personally run into but lack of imagination is hardly a good excuse to implement arbitrary restrictions.
> Let alone using esoteric Unicode whitespace characters for indentation.
How do you know what's esoteric in other countries? I certainly don't. I'm not an expert in linguistics but I'm sure that people everywhere in the world write computer programs at this point.
> I think it is perfectly reasonable ...
Without any concrete justification? Why would entirely artificial restrictions ever be seen as reasonable?
What "boneheaded things with tabs" are you referring to? The picture I'm piecing together from your comments suggests that you may use tab characters in a different way than most people seem to, so I'd quite like a further explanation of how you use tab characters and how you expect an editor to handle them.
> you may use tab characters in a different way than most people seem to
As far as I'm aware there are three primary and entirely independent uses for tabs. Indentation, field separation, and typesetting. When it comes to typesetting and also to display of fields with a narrow maximum width the concept of a tabstop is useful.
Boneheaded things with tabs was in reference to code editors (where tabs are more or less exclusively used for indentation) most often failing to provide the ability to disable tabstop. In practice this generally hasn't been a point of friction because until fairly recently the most popular languages (ie C & co) didn't support constructs that would lead to adding any indentation outside of the prefix of a line.
Agreed... but see my Lisp example in https://news.ycombinator.com/item?id=49593406 for a place where tabs end up unavoidably ambiguous. Because in that `cond` example the tabs look like they're used for indentation, but they're actually being used for alignment, something that falls more under typesetting than under indentation. A smart editor that has read the Lisp code (note that I'm using "read" in its Lisp meaning, i.e. "parsed into a syntax tree") can make those tab characters correctly align the forms the way you'd want them to be aligned for maximum understanding... but really, you would want space characters, not tab characters, in that context.
So even though in most cases those three uses for tabs are independent, in some languages they get muddled. F# is another language where you may want to align text on line two with the middle of line one, e.g. if you write
Now, that's considered bad style according to https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... — and they're entirely write to recommend against that style — but it's legal syntax. And it's probably why https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... forbids tab characters entirely in F# code.(Those two links point to different anchors in the same document, BTW: the HN link shortening is going to make them look identical until you hover over them).
The cond example commits a sin (see my other reply), in the F# example tabs (were they permitted) would introduce no ambiguity if used solely to communicate indentation, and the only change I would make to the F# example were I formatting it myself would be to also align the `=` characters. Actually that supposedly bad style is more or less exactly how I write nix expressions (as a matter of practicality I do not use tabs when writing those FWIW).
I agree that the cond example is committing the sin of trying to align with tabs. I wrote it because I had misunderstood something you were saying. But also, I've personally seen situations like this. I was working in a team whose indentation convention was "one tab character per indent level", and I had written some C# code like this:
And then to my horror I noticed that the editor (earlier I said it was VS Code, but thinking back I think it was actually Visual Studio) had produced this monstrosity: (Actual number of tabs was different, of course, and I believe it was followed at the end by a space or two, whereas my example happened to line up without needing an extra space character).I know not to do that. The editor did it anyway, and if I hadn't been paying close attention to whitespace I might not have caught it.
The editor could have been smart enough to parse the code into an AST, notice that param3 and param4 were part of a parameter group, and said "I will use tab characters equal to the indentation of `var result`, then spaces thereafter". It didn't. I had to edit the call to look like this:
And then I was safe from the editor trying to align things with tab characters.If my memory is right about which office I was working in when I saw the editor do that to my code, then it was more than a decade ago, probably around 2010 or 2011. It's possible that the modern version of that editor has improved its handling, and would have correctly aligned param3 with spaces. I haven't checked recently. Maybe at some point I will, and report my findings.
> <space><space><tab><space> is different than <space><tab><space><space>
in my view, both are the same, both `is` (or ===) an IndentationError raise
It's just a stack containing strings at the end of the day. Really not a big deal.
Right, pointers to strings but yeah. Essentially the whitespace count specifies the stack depth at which a line is to be executed. A decrease in stack depth means all superior levels are terminated.
Doesn't affect function call stacks though.
For a 1024 byte implementation (and even way more complex impl.) You would just force one whitespace char, and definitely no mixing.
> 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 modern languages have a regular lexical grammar anyway. Without significant indentation, some other features still require the lexer to maintain a stack - e.g. string interpolation (Python's f-strings).
> that criticism is usually posited by users of the language.
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.
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.
I meant users of languages ( application programmers) as opposed to compiler programmers, not python programmers specifically, so I'm including devs that use other languages and see in python a tool that they would consume.
the blog post is pretty well-written! loved how he wrote about the the code-golfing part.
tl;dr:
1. Choose a small fragment of the language
2. Adapt an existing interpreter
3. Use a tool to shorten the code, 'minify'
I don't understand the point of this. If they wanted to make a Python interpreter, why didn't they just ask an AI to do it?
> To feel human, I write code by hand on the weekends.
"Things won are done; joy’s soul lies in the doing." - Troilus and Cressida
Why do anything. Why even do the AI version of this.
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.
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.