'\n' कहाँ से आता है?

 (rodarmor.com)
1 पॉइंट द्वारा GN⁺ 2024-10-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें

'\n' का स्रोत

  • just foo कमांड चलाने पर, justfile bar नाम की फ़ाइल में 0x0A बाइट लिखता है
  • just Rust में लिखा गया है, और just parser cook_string नामक फ़ंक्शन के ज़रिए escape sequence वाले just string token को UTF-8 string में बदलता है

Rust में प्रसंस्करण

  • rustc escape code को scan_escape नामक फ़ंक्शन में प्रोसेस करता है
  • rustc Rust में लिखा गया है और self-hosting के साथ compile होता है, इसलिए '\n' का अर्थ समझने के लिए यह rustc पर निर्भर करता है
  • rustc के शुरुआती version OCaml में लिखे गए थे, और OCaml version का rustc lexer में character escape को प्रोसेस करता था

OCaml में प्रसंस्करण

  • OCaml compiler \n को \010 के रूप में evaluate करता है और परिणाम को शामिल करता है
  • 0x0A, 10 के बराबर है, इसलिए जब OCaml compiler \n को प्रोसेस करता है, तो उसे 0x0A बाइट मान मिलता है

निष्कर्ष

  • justfile में \n character escape होने पर, just binary 0x0A बाइट सहित अंतिम string को लिखता है
  • यह 0x0A बाइट rustc द्वारा डाली गई थी, और इसकी शुरुआत वहाँ से हुई जहाँ OCaml compiler ने पहली बार rustc binary में 0x0A बाइट डाली

GN⁺ का सारांश

  • यह लेख बताता है कि \n character escape कैसे 0x0A बाइट में बदलता है
  • Rust और OCaml compiler के ऐतिहासिक संदर्भ के माध्यम से 0x0A बाइट के स्रोत का पता लगाया गया है
  • यह प्रोग्रामिंग भाषाओं के compiler character escape को कैसे प्रोसेस करते हैं, इस पर एक दिलचस्प अंतर्दृष्टि देता है
  • यह Rust और OCaml के compiler behavior को समझने में मददगार लेख है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-07
Hacker News राय

  • एक उपयोगकर्ता ने उल्लेख किया कि उन्होंने यह विचार पहली बार "How I wrote a self-hosting C compiler in 40 days" नामक लेख के 42वें दिन पढ़ा था

    • इस लेख में बताया गया है कि compiler string literal में "\n" की व्याख्या कैसे करता है
    • इसमें समझाया गया है कि "\n" में वास्तविक ASCII character code जानकारी शामिल नहीं होती, बल्कि compiler को compile करते समय यह आगे पहुंचाई जाती है
    • यह भी उल्लेख किया गया है कि इस compiler का newline character GCC से आया था

  • EBCDIC सिस्टम के बारे में कहा गया कि यह ध्यान में रखना चाहिए कि शुरुआती C compiler ASCII के अलावा अन्य सिस्टम पर भी मौजूद थे

    • EBCDIC में स्पष्ट NextLine और LineFeed character होते थे
    • समझाया गया कि ASCII पर चलने वाला सरल code, EBCDIC पर विफल हो सकता है
    • EBCDIC में lowercase, uppercase से पहले आता है, और characters, numbers से पहले आते हैं; यानी इसकी ordering ASCII के बिल्कुल उलट है

  • C standard में character encoding के बारे में एकमात्र गारंटी यह है कि '0'-'9' अंक लगातार बढ़ते क्रम में map होते हैं

    • सैद्धांतिक रूप से, एक सरल C program को ASCII या EBCDIC सिस्टम पर उसी source से compile करने पर एक जैसा output देना चाहिए

  • एक उपयोगकर्ता ने Ken Thompson के Turing Award lecture "Reflections on Trusting Trust" का उल्लेख किया और अनुमान लगाया कि यह लेख शायद उसी lecture से प्रेरित था

  • यह जानने की जिज्ञासा जताई गई कि क्या clang compiler में भी यही गुण है; बताया गया कि यह lib/Lex/LiteralSupport.cpp में स्पष्ट रूप से 10 के रूप में coded है

  • एक उपयोगकर्ता ने पूछा कि "\n" को 10 के रूप में encode किए जाने को समझने के लिए खोजबीन की ज़रूरत क्यों पड़ी, क्योंकि उन्हें यह अपेक्षित लगा

  • कहा गया कि यह लेख literary programming और कविता के मेल की तरह पढ़ा जाता है, और यह समझाने की कोशिश करता है कि code generation के सैकड़ों cycle के जरिए 0x0A byte कैसे बनता है

  • एक उपयोगकर्ता ने बताया कि C भाषा की वजह से वे "\0???" को octal escape मानते थे, इसलिए "\012" को "\x0a" या "0x0a" और "\010" को "0x08" के रूप में समझते थे

    • उन्होंने अनुमान लगाया कि OCaml में octal escape के बजाय decimal escape हो सकते हैं

  • यह एक दिलचस्प सवाल उठाया गया कि अगर ASCII या strings में escape code न होते, तो हमारा code कैसा दिखता

  • यह भी कहा गया कि programming का एक नियम है: जब किसी काम के दो तरीके हों, और एक सही व दूसरा गलत होने की संभावना 50/50 लगे, तो शुरुआत में गलत वाला चुन लेने की संभावना ज़्यादा होती है