2 ms·

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

> 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 could be written (or even already exists) that would find that useful. Who is any third party to dictate that? U+00A0 similarly communicates information about the desired formatting and I can see no reason it would be unreasonable for someone to use it nor why its use should pose a technical challenge to a compiler. > creates problems for whitespace-sensitive langauge Does it? That seems like an invented problem to me. You have a running prefix composed of arbitrary whitespace characters. Any change in that prefix is a change in the level of indentation. You can add or remove arbitrary amounts from the end of the prefix. In the event you remove from it the result must exactly match the previous stack level. What's so complicated about this? > outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations ... Did you mix up your code points there? It's space that's ambiguous, not tab. Regardless I think that a compiler worrying about the specifics of text editors or other tooling would be backward information flow and a massive abstraction violation. Semantic meaning is entirely dictated by the compiler, not the other way around. There's no convincing reason (IMO) to impose restrictions that aren't technically necessary or to otherwise needlessly employ solutions that would reduce generalization.

rmunn 1mo ago
> 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?
- fc417fc802 1mo ago
  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.)
  - zephen 1mo ago
    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.
    - fc417fc802 1mo ago
      > 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.

rmunn 1mo ago

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

fc417fc802 1mo ago
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.)
- zephen 1mo ago
  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.
  - fc417fc802 1mo ago
    > 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.