Czy parser Haskell powinien dopuszczać cyfry Unicode w literałach numerycznych?

Jako ćwiczenie piszę parser Haskella od zera. Tworząc leksyk zauważyłem następujące zasady dotyczące raportu Haskell 2010 :

cyfra → ascDigit | uniDigit
ascDigit → 0| 1| … | 9
uniDigit → dowolny Unicode cyfry dziesiętne
octit → 0| 1| … | 7
hexit → cyfra | A| … | F| a| … |f

dziesiętny → cyfra { cyfra }
ósemkowy → octit { octit }
szesnastkowy → hexit { hexit }

liczba całkowita → dziesiętny | 0o ósemkowy | 0O ósemkowy | 0x szesnastkowy | 0X szesnastkowy
pływak → dziesiętny . dziesiętny [ wykładnik ] | dziesiętny wykładnik
wykładnik → ( e| E) [ +| -] dziesiętny

Literały dziesiętne i szesnastkowe, wraz z literami zmiennoprzecinkowymi, są oparte na cyfrach , które dopuszczają dowolną cyfrę dziesiętną Unicode, zamiast ascDigit , która dopuszcza tylko podstawowe cyfry 0-9 z ASCII. Co dziwne, ósemkowy jest oparta na octit , który zamiast tylko przyznaje ASCII cyfr 0-7. Domyślam się, że te „cyfry dziesiętne Unicode” są dowolnymi punktami kodowymi Unicode z kategorii ogólnej „Nd”. Obejmuje to jednak takie znaki, jak cyfry pełnej szerokości ０-９ i cyfry Devanagari ०-९. Rozumiem, dlaczego pożądane może być dopuszczenie ich w identyfikatorach, ale nie widzę żadnej korzyści z umożliwienia pisania ९０dla literału 90.

GHC wydaje się ze mną zgadzać. Kiedy próbuję skompilować ten plik,

module DigitTest where
x1 = １

wyrzuca ten błąd.

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

Jednak ten plik

module DigitTest where
x１ = 1

kompiluje się dobrze. Czy źle czytam specyfikację języka? Czy zachowanie (rozsądne) GHC jest rzeczywiście prawidłowe, czy technicznie jest niezgodne ze specyfikacją w Raporcie? Nigdzie nie mogę o tym wspominać.

— Ian Scherer
źródło

Zabawny. Podejrzewam, że stało się tak: „Ok, więc dosłownie składają się z cyfr ASCII, to proste”. „Nie czekaj, pomyślmy o internacjonalizacji, Unicode… mają też inne cyfry, prawda?” „Och tak, eh, nigdy się tym nie zajmowałem ... ale dobrze, wstawmy do tego klauzulę ...” „Świetnie”. ... a potem zostało po prostu zapomniane i nikt tak naprawdę nie zadał sobie trudu, aby go wdrożyć, ani nie zauważył, że nie ma sensu zezwalać na mieszanie różnych rodzin cyfr.

— leftaroundabout

Yikes. Tak, nie przejmuj się tym.

— Boann

W pliku kodu źródłowego GHC compiler/parser/Lexer.xmożna znaleźć następujący kod:

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

Tutaj $decdigitjest używany do analizy literałów dziesiętnych i szesnastkowych (i ich wariantów zmiennoprzecinkowych), natomiast $digitjest używany do „numerycznej” części identyfikatorów alfanumerycznych. Notatka „Do zrobienia” wyjaśnia, że jest to uznane odchylenie GHC od standardu językowego.

Więc czytasz specyfikację poprawnie, a GHC celowo narusza specyfikację. Istnieje otwarty bilet, który sugeruje przynajmniej udokumentowanie odchylenia, ale nie sądzę, aby ktokolwiek wyraził zainteresowanie naprawieniem tego.

— KA Buhr
źródło

Wszystkie trzy wymienione tam odchylenia są dość rozsądne. Rozumiem, dlaczego nie ma potrzeby ich „naprawiać”.

— Ian Scherer