3 ms·

The thing is, why 10? Why not 9 or 11? The code says "if you see 'string of newline character', output 'newline character'". How does the compiler know what a n

by crote 2y ago

The thing is, why 10? Why not 9 or 11? The code says "if you see 'string of newline character', output 'newline character'". How does the compiler know what a newline character is? Its code in turn just says "if you see 'string of newline character', treat it as 'newline character'"... As a human I can just Google "C string escape codes", but that table is nowhere to be found inside the compiler. If C 2025 is going to define Start of Heading as \h, is `'h' => cooked.push('\h')` going to magically start working? How could it possibly know? Clearly at some point someone must've manually programmed a `'n' => 10` mapping, but where is it!?

TacticalCoder 2y ago
> The thing is, why 10? Why not 9 or 11? Check the first Unicode codepoints, 10 is defined there: 000A is LINE FEED (LF) = new line (NL), end of line (EOL) It was already 10 in ASCII too (and the first 128 codepoints of Unicode are mostly the same as ASCII [I think there are a few tiny differences in some control characters]). So to answer your question: it's neither 9 nor 11 because '\n' stands for "new line" and not for "character tabulation" nor for "line tabulation" (which 9 and 11 respectively stands for). > Clearly at some point someone must've manually programmed a `'n' => 10` mapping I don't disagree with that.
- antonvs 2y ago
  > Check the first Unicode codepoints, 10 is defined there The point is how the compiler knows that. Read the article.
  - johnisgood 2y ago
    Does https://news.ycombinator.com/item?id=41764555 https://news.ycombinator.com/item?id=41764555 answer the question?
kreco 2y ago
> The thing is, why 10? Why not 9 or 11? The code says "if you see 'string of newline character', output 'newline character'". How does the compiler know what a newline character is? Its code in turn just says "if you see 'string of newline character', treat it as 'newline character'"... You can look into the ascii table then. 10 is the line feed. '\n' is there to help human because it makes more sense than '10'. Nobody is asking why 'a' is equal to '61'. From the codebase, you know that '\n' is a char. A char is a value between 0 and 255, if you explicitly convert '\n' to int then you happen to find the ascii value and you are good to go and there is no need to pretend there is any poetry in this. Requoting you: > "if you see 'string of newline character', output 'newline character'" It simply becomes "if a you see 'the arbitrary symbol for the new line', output 'the corresponding ascii value'". I read the quote as "if you see 'a', output 'a' in ascii code." which is not mysterious in any kind of way. IMO, the article does not make sense at all because it pretends to wonder where an hexadecimal value is coming from, but with any other kind of symbol it would be the exact same article, you enter 'a' and find some weird hexadecimal value and you won't be able to correctly trace it from the source code. It would make sense it 'a' would display 'a' but '\n' would display some hexadecimal garbage in a text editor.
- LegionMammal978 2y ago
  > From the codebase, you know that '\n' is a char. A char is a value between 0 and 255, if you explicitly convert '\n' to int then you happen to find the ascii value and you are good to go and there is no need to pretend there is any poetry in this. But how does the computer know which int to output when you "explicitly convert '\n' to int"? As humans, we can clearly just consult the ASCII table and/or the relevant language standard, but the computer doesn't have a brain and a pair of eyes, instead it must store that association somewhere. The purpose of this article is to locate where the association was originally entered into the source code by some human. The question is less interesting for ordinary characters like 'a', since the codes for those are presumably baked into the keyboard hardware and the font files, and no further translation is needed.
  - floren 2y ago
    > The question is less interesting for ordinary characters like 'a', since the codes for those are presumably baked into the keyboard hardware and the font files, and no further translation is needed. It's true that the question is less interesting for regular characters, but your explanation why is way off base. Consider a computer whose only I/O is a serial console. It is concerned with neither a keyboard nor a font file.
    - LegionMammal978 2y ago
      For a computer whose only I/O is a serial console, I'd say that it has no character 'a', but only a character 0x61 with such-and-such properties and relationships with other characters. It's when we press the 'A' key on our keyboard and get 0x61 out, or put 0x61 in and see the glyph 'a' on a display or a printout, that the code becomes associated with our human concept of the letter. That is, suppose I design a font file so that character 0x61 has glyph 'b' and 0x62 has glyph 'a', and I accordingly swap the key caps for 'A' and 'B' on my keyboard. If I write a document with this font file and print it off, then no one looking at it could tell that my characters had the wrong codes. Only the spell-checker on my computer would complain, since it's still following its designers' ideas of the character codes 0x61 and 0x62 are supposed to mean within a word.

by crote 2y ago

TacticalCoder 2y ago

> The thing is, why 10? Why not 9 or 11? Check the first Unicode codepoints, 10 is defined there: 000A is LINE FEED (LF) = new line (NL), end of line (EOL) It was already 10 in ASCII too (and the first 128 codepoints of Unicode are mostly the same as ASCII [I think there are a few tiny differences in some control characters]). So to answer your question: it's neither 9 nor 11 because '\n' stands for "new line" and not for "character tabulation" nor for "line tabulation" (which 9 and 11 respectively stands for). > Clearly at some point someone must've manually programmed a `'n' => 10` mapping I don't disagree with that.

antonvs 2y ago
> Check the first Unicode codepoints, 10 is defined there The point is how the compiler knows that. Read the article.
- johnisgood 2y ago
  Does https://news.ycombinator.com/item?id=41764555 https://news.ycombinator.com/item?id=41764555 answer the question?

kreco 2y ago

> The thing is, why 10? Why not 9 or 11? The code says "if you see 'string of newline character', output 'newline character'". How does the compiler know what a newline character is? Its code in turn just says "if you see 'string of newline character', treat it as 'newline character'"... You can look into the ascii table then. 10 is the line feed. '\n' is there to help human because it makes more sense than '10'. Nobody is asking why 'a' is equal to '61'. From the codebase, you know that '\n' is a char. A char is a value between 0 and 255, if you explicitly convert '\n' to int then you happen to find the ascii value and you are good to go and there is no need to pretend there is any poetry in this. Requoting you: > "if you see 'string of newline character', output 'newline character'" It simply becomes "if a you see 'the arbitrary symbol for the new line', output 'the corresponding ascii value'". I read the quote as "if you see 'a', output 'a' in ascii code." which is not mysterious in any kind of way. IMO, the article does not make sense at all because it pretends to wonder where an hexadecimal value is coming from, but with any other kind of symbol it would be the exact same article, you enter 'a' and find some weird hexadecimal value and you won't be able to correctly trace it from the source code. It would make sense it 'a' would display 'a' but '\n' would display some hexadecimal garbage in a text editor.

LegionMammal978 2y ago
> From the codebase, you know that '\n' is a char. A char is a value between 0 and 255, if you explicitly convert '\n' to int then you happen to find the ascii value and you are good to go and there is no need to pretend there is any poetry in this. But how does the computer know which int to output when you "explicitly convert '\n' to int"? As humans, we can clearly just consult the ASCII table and/or the relevant language standard, but the computer doesn't have a brain and a pair of eyes, instead it must store that association somewhere. The purpose of this article is to locate where the association was originally entered into the source code by some human. The question is less interesting for ordinary characters like 'a', since the codes for those are presumably baked into the keyboard hardware and the font files, and no further translation is needed.
- floren 2y ago
  > The question is less interesting for ordinary characters like 'a', since the codes for those are presumably baked into the keyboard hardware and the font files, and no further translation is needed. It's true that the question is less interesting for regular characters, but your explanation why is way off base. Consider a computer whose only I/O is a serial console. It is concerned with neither a keyboard nor a font file.
  - LegionMammal978 2y ago
    For a computer whose only I/O is a serial console, I'd say that it has no character 'a', but only a character 0x61 with such-and-such properties and relationships with other characters. It's when we press the 'A' key on our keyboard and get 0x61 out, or put 0x61 in and see the glyph 'a' on a display or a printout, that the code becomes associated with our human concept of the letter. That is, suppose I design a font file so that character 0x61 has glyph 'b' and 0x62 has glyph 'a', and I accordingly swap the key caps for 'A' and 'B' on my keyboard. If I write a document with this font file and print it off, then no one looking at it could tell that my characters had the wrong codes. Only the spell-checker on my computer would complain, since it's still following its designers' ideas of the character codes 0x61 and 0x62 are supposed to mean within a word.