WAVE's formal description is currently ambiguous wrt nan and inf which can be interpreted either as float literals (not-a-number and infinity) or as variant case labels.
Additionally, the language description side-steps other similar potential ambiguities with bool (true, false), option (some(...), none) and result (ok(...), err(...)) types by grouping them all under the variant-case rule.
As with #17 the WAVE parser in this repo avoids this ambiguity by being type-driven, but another implementation may want to parse to an unambiguous AST.
Two options:
Remove nan and inf from the number rule and group them under variant-case. This would - annoyingly - leave behind -inf which isn't a valid variant-case.
Reserve some or all of the ambiguous labels as keyword tokens and require %-prefixing for variant labels that use these keywords. Sub-options here:
Reserve only nan and inf
Additionally reserve true and false (which could tenuously be argued to be variants)
Additionally reserve some, none, ok, err (which could less-tenuously be argued to be variants)
WAVE's formal description is currently ambiguous wrt
nan
andinf
which can be interpreted either as float literals (not-a-number and infinity) or as variant case labels.Additionally, the language description side-steps other similar potential ambiguities with
bool
(true
,false
),option
(some(...)
,none
) andresult
(ok(...)
,err(...)
) types by grouping them all under thevariant-case
rule.As with #17 the WAVE parser in this repo avoids this ambiguity by being type-driven, but another implementation may want to parse to an unambiguous AST.
Two options:
nan
andinf
from thenumber
rule and group them undervariant-case
. This would - annoyingly - leave behind-inf
which isn't a validvariant-case
.%
-prefixing for variant labels that use these keywords. Sub-options here:nan
andinf
true
andfalse
(which could tenuously be argued to be variants)some
,none
,ok
,err
(which could less-tenuously be argued to be variants)