-
-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable EQUS
expansion for raw symbols (by parsing them as strings)
#1648
Conversation
EQUS
expansion for raw symbols ("the parser approach")EQUS
expansion for raw symbols (by parsing them as strings)
fec4d46
to
e5ce516
Compare
What feels natural to me about this:
The downsides:
|
e5ce516
to
6c0b1ed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I like this PR better than the lexer approach, as it feels more coherent from a language PoV. (In fewer words: “less lexer hack = good”).
I do feel that, while this PR is less hacky, it's also more fragile, due to all the code repetition; however, as I suggested in one of my comments, I think this could be solved by doing a bit of refactoring.
I also did not duplicate my comment from #1649 on the man page, but since that change is identical, it applies here too.
c384429
to
b2b3486
Compare
3bcaea9
to
a4b1439
Compare
a4b1439
to
cc64b35
Compare
Thanks to ISSOtm for helping settle on and refactor this approach! <3 |
Fixes #1605
The goal here is to make
#raw
string symbols get treated like string literals/expressions instead of gettingEQUS
-expanded. The long-term goal is to implement that in a way compatible with removingEQUS
expansion for all symbols (#905).This approach works by just having the lexer disable
EQUS
expansion for all#raw
symbols, so they get lexed asID
(orLABEL
). Then most of the work is done in the parser. There are three kinds of things: clearly numeric expressions (42
,2 + 3
, etc), clearly string expressions ("lol"
,STRSUB("hello", 1, 4)
, etc), and identifiers, whose role depends on their context and the type of the symbol corresponding to that identifier. So now, in addition to therelocexpr_no_str
distinction, it needs astring_literal
distinction.This PR needs further comparison with the alternative lexer-based approach implemented in #1649.