Glyphs and Latin

Glyphs and operators#

Faber ऐसे ग्लिफ़ का उपयोग करता है जिनमें प्रतीक संरचनात्मक भूमिका निभाता है। नीचे लेक्सर द्वारा पहचाने जाने वाले स्रोत ग्लिफ़ का पूरा संग्रह दिया गया है।

मान प्रवाह#

प्रकार का आकार#

तुलना#

तार्किक और बिटवाइज़#

असाइनमेंट अपडेट#

वैकल्पिक चेनिंग और नॉन-नल अभिकथन#

रेंज#

लिटरल सीमांकक#

विराम-चिह्न#

Latin vocabulary and structural glyphs#

तीन संकेत-चयन, जिनसे Faber स्रोत को एक नज़र में पहचाना जा सकता है।

Faber तीन ऐसे जानबूझकर चुने गए संकेतों का उपयोग करता है, जो मिलकर एक स्थिर व्याकरणिक आकार वाला स्रोत तैयार करते हैं। पाठक यह समझ सकता है कि हर रचना की अर्थगत भूमिका क्या है, भले ही उसे अभी यह न पता हो कि कोड किस लक्ष्य बैकएंड के लिए संकलित होगा।

तीन संकेत#

इन तीनों को एक-दूसरे को मजबूत करने के लिए बनाया गया है। जो पाठक किसी एक locale में Faber जानता है, वह इसे किसी भी locale में पढ़ सकता है, क्योंकि ग्लिफ़ और संरचना कभी नहीं बदलते। जो पाठक Rust बैकएंड जानता है, वह भी Faber स्रोत को पहचान सकता है, क्योंकि लैटिन कीवर्ड और प्रकार-प्रथम क्रम एक विशिष्ट दृश्य रूप बनाते हैं।

प्रकार-प्रथम घोषणाएँ#

Faber हर घोषणा में नाम से पहले प्रकार रखता है। यह मुख्यधारा के C-परिवार के सिंटैक्स के विपरीत है, और यह जानबूझकर किया गया है:

प्रकार-प्रथम घोषणाओं में डेटा का आकार सबसे पहले दिखाई देता है। यह उन भाषाओं के साथ स्वाभाविक रूप से मेल खाता है, जो अर्थगत विस्तार के लिए बाएँ से दाएँ पढ़ी जाती हैं — चीनी, हिंदी और अरबी घोषणाएँ भी यही क्रम अपनाती हैं।

फलन divide(संख्या a, संख्या b) → संख्या ∪ शून्य {
    यदि b ≡ 0 अतः लौटाओ शून्य
    लौटाओ a / b
}

लैटिन व्यवहारिक शब्दावली#

Faber हर उस रचना के लिए लैटिन शब्दों का उपयोग करता है, जिसमें व्यवहारिक या व्याकरणिक आकार होता है। यह शब्दावली छोटी और नियमित है। यह अधिकांश प्रोग्रामिंग भाषाओं की मिश्रित व्युत्पत्तियों के बजाय एक ही शास्त्रीय स्रोत से ली गई है।

घोषणाएँ#

बाइंडिंग और स्थानांतरण#

नियंत्रण प्रवाह#

लैटिन शब्दावली बाइंड करने योग्य है — यह कैनोनिकल पैक के साथ आती है, लेकिन reader locale के माध्यम से इसे फिर से मैप किया जा सकता है। थाई प्रोग्रामर को si के स्थान पर ถ้า दिखाई देता है; चीनी प्रोग्रामर को functio के स्थान पर 函数 दिखाई देता है। शब्दावली को विशेषाधिकार प्राप्त नहीं है; केवल व्याकरण स्थिर रहता है।

संरचनात्मक ग्लिफ़#

जहाँ व्यवहारिक शब्दावली लैटिन शब्दों का उपयोग करती है, वहीं संरचनात्मक अर्थ सार्वभौमिक ग्लिफ़ का उपयोग करता है। ये कभी स्थानीयकृत नहीं होते और अलग-अलग रेंडरिंग में इनका अर्थ कभी नहीं बदलता। यही दृश्य आधार है, जो Faber स्रोत को पहचानने योग्य बनाता है, चाहे कीवर्ड किसी भी मानव भाषा में रेंडर किए गए हों।

मान-प्रवाह#

प्रकार का आकार#

तुलना और तर्क#

बाइंडिंग परंपरा महत्वपूर्ण है#

एक ग्लिफ़-चयन पर विशेष ध्यान देना चाहिए, क्योंकि नए पाठकों के लिए भ्रम का यह सबसे सामान्य बिंदु है:

अधिकांश भाषाएँ = को "इस प्रकार में यह फ़ील्ड परिभाषित करें" और "इस चर में रनटाइम मान रखें" — दोनों के लिए ओवरलोड करती हैं। Faber इन दोनों कार्यों को अलग करता है। हर ← सक्रिय डेटा-प्रवाह है; हर Type { … } के भीतर का = जीनस फ़ील्ड लेआउट है।

# Runtime binding: ← attaches a value to a name
fixum numerus count ← 0
varia textus label ← "ready"
count ← count + 1

# Structural shape: = defines field values inside a literal
fixum _ p ← Point {
    x = 10,
    y = 20
}

मुख्यधारा की भाषाओं की तुलना में#

नीचे दी गई तालिका दिखाती है कि प्रोग्रामिंग भाषाओं के सामान्य पैटर्न Faber की तीन-संकेत प्रणाली में कैसे मैप होते हैं। Faber कॉलम हर अलग अर्थगत कार्य के लिए अलग ग्लिफ़ या कीवर्ड का उपयोग करता है — कोई ओवरलोडिंग नहीं।

संदर्भ#

1. EBNF व्याकरण — ग्लिफ़ और कीवर्ड की पूरी सूची
2. examples/corpus/ — सभी कीवर्ड वाली 292 उदाहरण फ़ाइलों का भाषा कॉर्पस
3. examples/corpus/operatores/ — ऑपरेटर और ग्लिफ़ के उदाहरण
4. Commandments — इन संकेतों को सुरक्षित रखने वाले डिज़ाइन के नौ नियम

Canonical vs sugar surfaces#

एक ही अर्थ-रूप वाली अनेक पार्स की जा सकने वाली सतहें।

Faber के डिज़ाइन में एक पैटर्न बार-बार दिखाई देता है: भाषा हर construct के लिए एक canonical spelling निर्धारित करती है, लेकिन कई sugar spellings स्वीकार करती है जो अर्थ की दृष्टि से समान होती हैं। Compiler इनमें से किसी एक को प्राथमिकता नहीं देता — दोनों एक ही AST node में parse होते हैं। Formatter संदर्भ और mode के आधार पर यह तय करता है कि कौन-सी spelling emit करनी है।

नियम: Sugar spellings, long form के अर्थ की दृष्टि से समान होती हैं। कई सतहें एक ही HirAnnotation या type node में parse होती हैं। faber format --canonical canonical spellings को प्राथमिकता देता है; author mode लेखक द्वारा लिखी गई sugar को सुरक्षित रखता है।

संख्यात्मक प्रकार शुगर#

Numeric types के canonical spellings long form में होते हैं और इनके compact sugar forms भी होते हैं। यह चुनाव repository-स्तर पर नहीं, module-स्तर पर होता है — कोई CLI package हर जगह long form का उपयोग कर सकता है, जबकि कोई tensor kernel module sugar का उपयोग कर सकता है:

सामान्य Faber (long form को प्राथमिकता दें):

स्थिर सूची<f32> values ← खाली

स्थिर टेंसर<f32, [2, 3]> grid ← खाली

स्थिर संख्या<i32> narrow ← 7

Numeric modules (sugar को प्राथमिकता दें):

स्थिर सूची<f32> values ← खाली

स्थिर टेंसर<f32, [2, 3]> grid ← खाली

स्थिर संख्या<i32> narrow ← 7

Sugar केवल type-position में मान्य है। f32, tf32, या mf32 नाम वाले value identifiers अपरिवर्तित रहते हैं — compiler इन्हें केवल type positions में आने पर sugar के रूप में समझता है। जो file लगातार sugar का उपयोग करती है, उसे शीर्ष पर एक बार यह बात बतानी चाहिए:

# STYLE: numeric sugar (tf32, mf32, sf32, lf32, lu32)

एनोटेशन शुगर#

Faber annotations भी numeric types की तरह dual-surface model का पालन करते हैं। Annotations, declarations से जुड़ा compiler-owned metadata हैं — जैसे CLI option definitions के लिए @ optio या async functions के लिए @ futura।

Canonical form: स्पष्ट field names वाला braced record:

@ optio {
    binding = verbose,
    brevis = "v",
    longum = "verbose",
    typus = bivalens,
    ubique = verum,
    descriptio = "Enable verbose output"
}

Sugar form: positional arguments और named aliases:

@ optio verbose brevis "v" longum "verbose" typus bivalens ubique descriptio "Enable verbose output"

दोनों forms एक ही HirAnnotation record बनाते हैं। Canonical form स्पष्ट और self-documenting है; sugar form उन annotations के लिए संक्षिप्त है जिनका अक्सर उपयोग होता है और जिनके field order को अच्छी तरह जाना जाता है। faber format --canonical braced records को प्राथमिकता देता है; author mode लेखक द्वारा चुना गया form सुरक्षित रखता है।

लेखक बनाम कैनोनिकल फ़ॉर्मैटिंग#

faber format command दो modes में काम करता है, जो canonical-vs-sugar principle को प्रतिबिंबित करते हैं:

दोनों modes compiler के पूरे front half से गुजरते हैं (canonical के लिए lex, parse और analyse)। Invalid source compiler diagnostics उत्पन्न करता है — formatter broken input को चुपचाप format नहीं करता।

दोनों modes के लिए मुख्य नियम:

• चार-space indentation
• Stroustrup braces: opening {, controlling header वाली उसी line पर होता है
• Author mode blank lines की उपस्थिति सुरक्षित रखता है, लेकिन एक से अधिक लगातार blank lines को समेट देता है
• Author mode ऐसी blank lines नहीं जोड़ता जो source में मौजूद नहीं थीं
• Canonical mode type spellings को long form में, tensor sugar को canonical रूप में और annotations को braced records में normalise करता है
• Canonical mode nullable unions के लिए T ∪ nihil और optional parameters के लिए sponte emit करता है

डिज़ाइन सिद्धांत#

Canonical-vs-sugar pattern कई स्थानों पर दिखाई देता है क्योंकि यह एक जानबूझकर अपनाया गया design principle है, न कि अलग-अलग सुविधाओं का संग्रह:

यह pattern दो उद्देश्यों की पूर्ति करता है। पहला, यह प्रवेश की बाधा कम करता है — नए users tensor<fractus<f32>, [4]> लिखे बिना tf32[4] लिख सकते हैं। दूसरा, यह canonical language को अस्पष्ट नहीं होने देता — जब precision महत्वपूर्ण हो, तो long form ठीक-ठीक बताता है कि उसका अर्थ क्या है। Formatter दोनों के बीच पुल का काम करता है: authors sugar लिखते हैं, reviewers canonical की मांग कर सकते हैं, और CI किसी भी रूप को लागू कर सकता है।

संदर्भ#

1. radix/docs/design/numeric-type-sugar.md — पूर्ण sugar families, spelling preferences
2. radix/docs/design/annotation-sugar.md — dual-surface annotation model
3. radix/docs/design/faber-canonical-surface.md — author बनाम canonical format policy
4. faber/docs/EBNF.md — sugar forms के grammar tables