क्या हास्केल पार्सर को यूनिकोड अंकों को संख्यात्मक शाब्दिकों में अनुमति देना चाहिए?

एक अभ्यास के रूप में, मैं स्क्रैच से हास्केल के लिए एक पार्सर लिख रहा हूं। लेसर बनाने में, मैंने हास्केल 2010 रिपोर्ट पर निम्नलिखित नियमों को देखा :

अंक → ascDigit | uniDigit
ascDigit → 0| 1| … | 9
uniDigit → कोई भी यूनिकोड दशमलव अंक
ऑक्टिट → 0| 1| … | 7
हेक्सिट → अंक | A| … | F| a| … |f

दशमलव → अंक { अंक }
ऑक्टल → ऑक्टिट { ऑक्टिट }
हेक्साडेसिमल → हेक्सिट { हेक्सिट }}

पूर्णांक → दशमलव | 0o अष्टदल | 0O अष्टदल | 0x हेक्साडेसिमल | 0X हेक्साडेसिमल
फ्लोट → दशमलव . दशमलव [ घातांक ] | दशमलव घातांक
घातांक → ( e| E) [ +| -] दशमलव

दशमलव और हेक्साडेसिमल शाब्दिक, फ्लोट शाब्दिक के साथ, सभी अंक पर आधारित होते हैं , जो किसी भी यूनिकोड दशमलव अंक को मानते हैं, एस्कडीजिट के बजाय , जो ASCII से केवल मूल अंक 0-9 को स्वीकार करता है। अजीब तरह से, ऑक्टल ऑक्टिट पर आधारित है , जो केवल ASCII अंक 0-4 को स्वीकार करता है। मुझे लगता है कि ये "यूनिकोड दशमलव अंक" किसी भी यूनिकोड कोडपॉइंट के साथ "एनडी" जनरल श्रेणी के होते हैं। हालाँकि, इसमें पूर्ण-चौड़ाई अंक ９- the और देवनागरी अंक ०-९ जैसे वर्ण शामिल हैं। मैं देख सकता हूं कि पहचानकर्ताओं में इनकी अनुमति देना क्यों वांछनीय हो सकता है, लेकिन मैं किसी को भी ९０शाब्दिक के लिए लिखने की अनुमति देने के लिए कोई लाभ नहीं देख सकता 90।

GHC मुझसे सहमत है। जब मैंने इस फ़ाइल को संकलित करने का प्रयास किया,

module DigitTest where
x1 = １

यह इस त्रुटि को दूर करता है।

digitTest1.hs:2:6: error: lexical error at character '\65297'
  |
2 | x1 = １
  |      ^

हालाँकि, यह फ़ाइल

module DigitTest where
x１ = 1

संकलन ठीक है। क्या मैं भाषा विनिर्देश को गलत तरीके से पढ़ रहा हूं? क्या GHC का (समझदार) व्यवहार वास्तव में सही है, या क्या यह तकनीकी रूप से रिपोर्ट में विनिर्देश के खिलाफ है? मुझे इसका कहीं भी कोई उल्लेख नहीं मिल रहा है।

— इयान शायर
स्रोत

मजेदार। मुझे संदेह है कि यह "ओके," जैसे कुछ के बारे में आया, इसलिए शाब्दिक में केवल ASCII अंक शामिल हैं, आसान। " "नहीं रुको, चलो अंतर्राष्ट्रीयकरण के बारे में सोचते हैं, यूनिकोड ... उनके पास अन्य अंक चिन्ह भी हैं, है ना?" "ओह, हाँ, एह, कभी नहीं निपटा ... लेकिन ठीक है, चलो उस के लिए एक खंड सम्मिलित करें ..." "महान।" ... और फिर यह सिर्फ भुला दिया गया और किसी ने वास्तव में इसे लागू करने में कभी परेशान नहीं किया, या ध्यान दिया कि यह अंकों के विभिन्न परिवारों को मिश्रण करने की अनुमति देने का कोई मतलब नहीं है।

— लेफ्टनैताबाउट

ओह। हाँ, इससे परेशान न हों।

— Boann

GHC स्रोत कोड फ़ाइल में compiler/parser/Lexer.x, आप निम्न कोड पा सकते हैं:

ascdigit  = 0-9
$unidigit  = \x03 -- Trick Alex into handling Unicode. See [Unicode in Alex].
$decdigit  = $ascdigit -- for now, should really be $digit (ToDo)
$digit     = [$ascdigit $unidigit]
...
$binit     = 0-1
$octit     = 0-7
$hexit     = [$decdigit A-F a-f]
...
@numspc       = _*                   -- numeric spacer (#14473)
@decimal      = $decdigit(@numspc $decdigit)*
@binary       = $binit(@numspc $binit)*
@octal        = $octit(@numspc $octit)*
@hexadecimal  = $hexit(@numspc $hexit)*
@exponent     = @numspc [eE] [\-\+]? @decimal
@bin_exponent = @numspc [pP] [\-\+]? @decimal

यहां, $decdigitदशमलव और हेक्साडेसिमल शाब्दिक (और उनके अस्थायी बिंदु वेरिएंट) को पार्स करने के लिए उपयोग किया जाता है, जबकि $digitअल्फ़ान्यूमेरिक पहचानकर्ताओं के "संख्यात्मक" भाग के लिए उपयोग किया जाता है। "ToDo" नोट यह स्पष्ट करता है कि यह भाषा मानक से GHC का एक मान्यता प्राप्त विचलन है।

इसलिए, आप युक्ति को सही ढंग से पढ़ रहे हैं, और GHC अर्ध-जानबूझकर युक्ति का उल्लंघन कर रहा है। एक खुला टिकट है जो कम से कम विचलन का दस्तावेजीकरण करने का सुझाव देता है, लेकिन मुझे नहीं लगता कि किसी ने भी इसे ठीक करने में कोई रुचि व्यक्त की है।

— केए बुहर
स्रोत

सूचीबद्ध सभी तीन विचलन काफी उचित हैं। मैं देख सकता हूं कि उन्हें "ठीक" करने की मांग क्यों नहीं है।

— इयान शायर