Skip to content

Comment on Making a Python interpreter in 1024 bytesparent

Comments

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.

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.

No, I vehemently disagree with most of what you wrote. We certainly agree on basic things that tabs do not have a fixed width, and that a "compiler never has any control over (source code) display." (What a bizarre idea; whoever said it did?)

I'd dispute that the compiler needs to care about where your editor places the left margin.

This isn't just about editors. I well remember green-bar.

As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.

No, if someone uses 8 character tabs, and then wants to space over half a tab for visual reasons, things completely break. We probably agree that's wrong, and that the answer is some variant of the answer to "Doc, it hurts when I do this" and I maintain the answer is to dispense with tabs completely.

Look the tabs-vs-spaces war is as old as the big-endian/little-endian war, and I am probably older than you. We'll probably never convince each other of any of this. Have a good day.

I could not successfully search for green-bar; I was turning up a brand of rebar made from fiberglass and various vegan bars and restaurants in different cities... but nothing related to coding or text editing. Do you have a link handy that would explain what the green-bar you're referring to is? Or, failing that, could I ask you for a brief (one or two sentences) explanation/summary? Would be appreciated. (UPDATE: Figured it out, see P.S. below)

BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.

EDIT to add this P.S.: Figured it out. I eventually came across https://elpa.gnu.org/packages/greenbar.html which mentioned the alternating white and green bands of color on old printer paper. I remember those, but I never heard them called "green-bar" which is why I couldn't place the term.

Sorry, didn't mean to send anybody on a wild goose chase. Glad you found a reference, and also somewhat glad that the reference says that the the term was "often" used -- maybe I'm not quite ready for the dementia ward yet?

BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.

I had to go back and look. You obviously have more patience than I do for this sort of debate. :-)

I don't think people who fall down on the tab side of the debate have thought things through. Tabs are about alignment, of course, but why did we transport the typewriter alignment to printers? (Many printers had escape sequences that let you set the tab spacing.) Arguably, it was to save computation time, storage space, data transmission time, and even (for faster printers) to make your print job come out faster. People forget how precious all those were.

Today, a tab key on a keyboard is a perfectly cromulent method to get to your next alignment boundary, but there's a reason that every single usable code editor lets you program the tab key to emit a certain number of spaces.

I'm sure it was often used, but I spent a lot of my childhood and early adolescence in the non-English-speaking country where my father worked for many years. So "green-bar paper" is not the only apparently-commonly-used English term that I had to learn later in life, since when I was growing up, I heard English mostly from my parents and coworkers, and that's not a term that they happened to use a lot. So although it's my native tongue, I'm constantly finding holes in my vocabulary — usually 80's or 90's slang terms that my (extensive) reading habit couldn't teach me because most of the English-language books I had access to in the 80's or 90's were published in the 1970's or earlier.

In other words, don't take my not knowing a term as evidence that it wasn't commonly used; my childhood was unusual by the standards of most Americans. :-)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.