¿De dónde viene '\n'?

El origen de '\n'

• Al ejecutar el comando just foo, justfile escribe el byte 0x0A en un archivo llamado bar
• just está escrito en Rust, y el parser de just convierte los tokens de cadena de just que incluyen secuencias de escape en cadenas UTF-8 mediante una función llamada cook_string

Cómo lo maneja Rust

• rustc procesa los códigos de escape en una función llamada scan_escape
• rustc está escrito en Rust y se compila a sí mismo, delegando en rustc la interpretación del significado de '\n'
• Las primeras versiones de rustc estaban escritas en OCaml, y la versión en OCaml de rustc procesaba los escapes de caracteres en el lexer

Cómo lo maneja OCaml

• El compilador de OCaml evalúa \n como \010 e inserta el resultado
• Como 0x0A es 10, cuando el compilador de OCaml procesa \n obtiene el valor de byte 0x0A

Conclusión

• Cuando hay un escape de carácter \n en justfile, el binario de just lo escribe en la cadena final incluyendo el byte 0x0A
• Ese byte 0x0A fue insertado por rustc, y esto comenzó cuando el compilador de OCaml insertó por primera vez el byte 0x0A en el binario de rustc

Resumen de GN⁺

• Este artículo explica cómo el escape de carácter \n se convierte en el byte 0x0A
• Sigue el origen del byte 0x0A a través del contexto histórico de los compiladores de Rust y OCaml
• Ofrece una perspectiva interesante sobre cómo los compiladores de lenguajes de programación procesan los escapes de caracteres
• Es un texto útil para entender el comportamiento de los compiladores de Rust y OCaml

[GN⁺]

Comentarios de Hacker News

• Un usuario menciona que la primera vez que leyó esta idea fue en el día 42 del texto "How I wrote a self-hosting C compiler in 40 days"

  • En ese texto se explica cómo el compilador interpreta "\n" dentro de un literal de cadena
  • Se explica que "\n" no contiene por sí mismo la información del código real del carácter ASCII, sino que esta se transmite cuando el compilador compila al compilador
  • Menciona que el carácter de salto de línea de este compilador proviene de GCC

• Señalan que, en sistemas EBCDIC, hay que considerar que los primeros compiladores de C aparecieron también en sistemas que no eran ASCII

  • EBCDIC tenía caracteres explícitos de NextLine y LineFeed
  • Explican que código simple que funciona en ASCII puede fallar en EBCDIC
  • En EBCDIC, las minúsculas van antes que las mayúsculas y las letras antes que los números, entre otras ordenaciones opuestas a ASCII

• En el estándar de C, la única garantía sobre la codificación de caracteres es que los dígitos '0'-'9' se mapean de forma ascendente y consecutiva

  • En teoría, un programa simple en C debería poder compilar el mismo código fuente en sistemas ASCII o EBCDIC y producir la misma salida

• Un usuario menciona la charla de aceptación del Turing Award de Ken Thompson, "Reflections on Trusting Trust", y especula que este texto pudo haberse inspirado en ella

• Se preguntan si el compilador clang tiene la misma propiedad, y explican que en lib/Lex/LiteralSupport.cpp esto está codificado explícitamente como 10

• Un usuario se pregunta por qué fue necesario investigar para entender por qué "\n" está codificado como 10, ya que le parecía lo esperado

• Mencionan que este texto se lee como una intersección entre programación literaria y poesía, e intenta explicar cómo se genera el byte 0x0A a través de cientos de ciclos de generación de código

• Un usuario explica que, por culpa del lenguaje C, pensaba que "\0???" era un escape octal, por lo que interpretaba "\012" como "\x0a" o "0x0a", y "\010" como "0x08"

  • Especula que OCaml podría tener escapes decimales en lugar de escapes octales

• Plantean la interesante pregunta de cómo se vería nuestro código si ASCII o las cadenas no tuvieran códigos de escape

• Mencionan una regla de la programación: cuando hay dos maneras de hacer algo, y parece que hay 50/50 de probabilidad de que una sea correcta y la otra incorrecta, al principio es más probable elegir la incorrecta