in v27.0, 0xF .Foo is considered an invalid expression because it appears the expression 0xF is followed by the keyword token .Foo. This can be made valid by adding a space after . (0xF . Foo). Note that 0xF.Foo is not what you want; it would be parsed as a floating-point hex custom literal equivalent to _oo"0xF.F"
In LES3 you can't write a C#/Java-style fluent expression like
Use("cool thing")
.With("other thing");
This is parsed as two statements because of the newline, so I wasn't really concerned that .With is also parsed as a keyword. But now that I'm planning to split LES3 into LESC and LESP, this code should be valid in LESC, so .With should not be treated as a keyword.
There appear to be two solutions.
Treat .With as a keyword in the lexer (that's the status quo) and then reinterpret it as if it were two tokens in the parser.
Treat .With as two tokens in the lexer.
On closer inspection, option 1 doesn't work because the parser always sees .With as a unit, but can't treat it as a unit in case of input like a .b!c, which must be parsed like a.(b!c).
However, option 2 tends to cause user-visible changes to token trees. In the latest build, (' .foo bar) means (#foo, bar), but if there is no keyword token, the natural output becomes (`'.`, foo, bar) instead. I'm inclined to think that this is acceptable. There will also be a slightly lower efficiency of keyword parsing; aside from the extra token, .foo x will first cause a symbol to be created for foo and then the parser will create a second symbol for #foo, on top of the string concat "#"+"foo" that was already happening.
qwertie
commented
4 years ago
in v27.0,
0xF .Foois considered an invalid expression because it appears the expression0xFis followed by the keyword token.Foo. This can be made valid by adding a space after.(0xF . Foo). Note that0xF.Foois not what you want; it would be parsed as a floating-point hex custom literal equivalent to_oo"0xF.F"In LES3 you can't write a C#/Java-style fluent expression like
This is parsed as two statements because of the newline, so I wasn't really concerned that
.Withis also parsed as a keyword. But now that I'm planning to split LES3 into LESC and LESP, this code should be valid in LESC, so.Withshould not be treated as a keyword.There appear to be two solutions.
.Withas a keyword in the lexer (that's the status quo) and then reinterpret it as if it were two tokens in the parser..Withas two tokens in the lexer.On closer inspection, option 1 doesn't work because the parser always sees
.Withas a unit, but can't treat it as a unit in case of input likea .b!c, which must be parsed likea.(b!c).However, option 2 tends to cause user-visible changes to token trees. In the latest build,
(' .foo bar)means(#foo, bar), but if there is no keyword token, the natural output becomes(`'.`, foo, bar)instead. I'm inclined to think that this is acceptable. There will also be a slightly lower efficiency of keyword parsing; aside from the extra token,.foo xwill first cause a symbol to be created forfooand then the parser will create a second symbol for#foo, on top of the string concat"#"+"foo"that was already happening.