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?
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.)
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)
((< 3 3) ’less)
(else ’equal))
(cond ((> 3 3) ’greater)
<tab>((< 3 3) ’less)
<tab>(else ’equal))
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.
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.
def example():
<tab>if True:
<tab><tab>do_something()
def example():
<tab>if True:
<tab><tab>do_something()
do_something_else()
def example():
if True:
do_something()
do_something_else()
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.
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.
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.)
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.
> 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.
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.