Parser defect: number should take priority over abbreviation
tyomitch opened this issue · comments
The reference says:
When the parser encounters a sequence of characters which could represent a symbol, or could represent a number or abbreviation, then the number or abbreviation will take priority.
Currently this means that numbers starting with a period are parsed as meth-name
, so e.g. (let decay-rate .05)
fails with an "error: unbound symbol 'meth-name'"
This is never helpful, as 05
is not a valid method name.
The parser is working as specified. We imitate Rust's syntax for numbers and strings wherever possible, and in Rust, .05
isn't a valid floating-point literal.
Leaving this issue open, because you've raised two good points:
-
We should definitely try to provide a better error message for incorrect use of the
meth-name
abbreviation. -
We could consider adopting a more relaxed syntax for floats in GameLisp, compared to Rust. There are a number of pros and cons. It would be more intuitive and convenient, but less consistent, and more difficult to document. It would require us to add a special-case to the parser, to disable the
meth-name
abbreviation for numbers. It would prevent us from adding any syntax like.0
which imitates Rust's tuple-indexing syntax.