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

51–60 of 120 posts

Re: Making a Python interpreter in 1024 bytes

#51

Post by rmunn »

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…

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:

    (cond ((> 3 3) ’greater)
          ((
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`:

    (cond ((> 3 3) ’greater)
    (((else ’equal))
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 `` 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.

Re: Making a Python interpreter in 1024 bytes

#52

Post by eclipticplane »

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

> 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

Re: Making a Python interpreter in 1024 bytes

#53

Post by rmunn »

fc417fc802 wrote: post #50
rmunn wrote: post #41

Earlier quoted context omitted.

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

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

Re: Making a Python interpreter in 1024 bytes

#55

Post by [deleted] »

eclipticplane wrote: post #52
kylecazar wrote: post #34

Earlier quoted context omitted.

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

[deleted]

Re: Making a Python interpreter in 1024 bytes

#56

Post by Forgeties79 »

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

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

Re: Making a Python interpreter in 1024 bytes

#57

Post by eru »

FridgeSeal wrote: post #45
eru wrote: post #30

Earlier quoted context omitted.

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?

That's the spirit!

(Slightly less silly: the folks at https://github.com/faster-cpython are doing great work, too.)

Re: Making a Python interpreter in 1024 bytes

#58

Post by Lerc »

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

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

Re: Making a Python interpreter in 1024 bytes

#60

Post by bblb »

ssfdg wrote: post #40

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?

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.

Post reply on HN