Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making a Python interpreter in 1024 bytes

austinhenley.com

Post reply on HN
Print view View original

41–50 of 120 posts

Re: Making a Python interpreter in 1024 bytes

#41

Post by rmunn »

fc417fc802 wrote: post #26
Mogzol wrote: post #21

Earlier quoted context omitted.

> and annoyingly restrictive How so? In what scenario would you ever need to use a sequence like 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 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 coun…

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.

Re: Making a Python interpreter in 1024 bytes

#43

Post by rmunn »

hmry wrote: post #37
rmunn wrote: post #6

Earlier quoted context omitted.

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 pr…

That seems like a decent way to handle the mixed-spaces-and-tabs scenario, even between lines: one line starts with ``, the next line ``, that's an indent. (Probably someone who likes 4-space indents and 8-space tab characters). Follow that up with `*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.

Re: Making a Python interpreter in 1024 bytes

#44

Post by fc417fc802 »

rmunn wrote: post #39
fc417fc802 wrote: post #35

Earlier quoted context omitted.

> 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…

> 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.)

Re: Making a Python interpreter in 1024 bytes

#45

Post by FridgeSeal »

eru wrote: post #30
jrdres wrote: post #24

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…

If you are willing to sacrifice performance, you can implement dicts via linear lookup in much less code than a proper hash table.

It’s Python, you’ve already sacrificed performance, what a little bit more?

Re: Making a Python interpreter in 1024 bytes

#46

Post by 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:

https://news.ycombinator.com/item?id=45800777

Re: Making a Python interpreter in 1024 bytes

#47

Post by userbinator »

anitil wrote: post #17

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.

Re: Making a Python interpreter in 1024 bytes

#48

Post by bolangi »

kylecazar wrote: post #34
marcelo-earth wrote: post #32

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

Thanks, this makes me happy.

Re: Making a Python interpreter in 1024 bytes

#49

Post by zephen »

fc417fc802 wrote: post #44
rmunn wrote: post #39

Earlier quoted context omitted.

> 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 di…

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.

Re: Making a Python interpreter in 1024 bytes

#50

Post by fc417fc802 »

rmunn wrote: post #41
fc417fc802 wrote: post #26

Earlier quoted context omitted.

> In what scenario would you ever need to use a sequence like 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 coun…

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.

Post reply on HN