Hacker News

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

    def example():
    <tab>if True:
    <tab><tab>do_something()

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:

    def example():
    <tab>if True:
    <tab><tab>do_something()
            do_something_else()

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.