Sollte ein Haskell-Parser Unicode-Ziffern in numerischen Literalen zulassen?

Als Übung schreibe ich einen Parser für Haskell von Grund auf neu. Bei der Erstellung des Lexers habe ich die folgenden Regeln im Haskell 2010-Bericht beachtet :

Ziffer → ascDigit | uniDigit
ascDigit → 0| 1| … | 9
uniDigit → beliebiges Unicode-Dezimalstellen-
Oktit → 0| 1| … | 7
hexit → Ziffer | A| … | F| a| … |f

Dezimal → Ziffer { Ziffer }
Oktal → Oktit { Oktit }
Hexadezimal → Hexit { Hexit }

Ganzzahl → Dezimalzahl | 0o oktal | 0O oktal | 0x hexadezimal | 0X hexadezimaler
Gleitkommawert → dezimaler . Dezimalwert [ Exponent ] | Dezimalexponenten
Exponent → ( e| E) [ +| -] dezimal

Dezimal- und Hexadezimalliterale sowie Float-Literale basieren alle auf einer Ziffer , die eine beliebige Unicode-Dezimalstelle zulässt, anstelle von ascDigit , die nur die Grundziffern 0-9 aus ASCII zulässt. Seltsamerweise basiert Oktal auf Oktit , das stattdessen nur die ASCII-Ziffern 0-7 zulässt. Ich würde vermuten, dass diese "Unicode-Dezimalstellen" beliebige Unicode-Codepunkte mit der allgemeinen Kategorie "Nd" sind. Dies schließt jedoch Zeichen wie die Ziffern Full-９ in voller Breite und die Devanagari-Ziffern ०-९ ein. Ich kann sehen, warum es wünschenswert sein könnte, diese in Bezeichnern zuzulassen, aber ich kann überhaupt keinen Vorteil darin sehen, dass man ९０für das Literal schreiben darf 90.

GHC scheint mir zuzustimmen. Wenn ich versuche, diese Datei zu kompilieren,

module DigitTest where
x1 = １

es spuckt diesen Fehler aus.

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

Allerdings diese Datei

module DigitTest where
x１ = 1

kompiliert ganz gut. Lese ich die Sprachspezifikation falsch? Ist das (vernünftige) Verhalten von GHC tatsächlich korrekt oder widerspricht es technisch der Spezifikation im Bericht? Ich kann das nirgendwo erwähnen.

In der GHC-Quellcodedatei compiler/parser/Lexer.xfinden Sie den folgenden Code:

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

Hier $decdigitwird zum Parsen von Dezimal- und Hexadezimalliteralen (und ihren Gleitkommavarianten) verwendet, während $digitfür den "numerischen" Teil von alphanumerischen Bezeichnern verwendet wird. Der Hinweis "ToDo" macht deutlich, dass dies eine anerkannte Abweichung von GHC vom Sprachstandard ist.

Sie lesen die Spezifikation also richtig und GHC verletzt die Spezifikation absichtlich. Es gibt ein offenes Ticket , das zumindest die Dokumentation der Abweichung vorschlägt, aber ich glaube, niemand hat Interesse daran bekundet, sie zu beheben.