Closed raehik closed 2 years ago
@dorchard Seems I get away with S/R conflicts by simply adding an "override" case to EXPRESSION
parser rules, without refactoring. This change would mean adding another case for all Expression
pattern matches, which should almost always be treated the same way as an ExpValue (ValVariable name)
.
I wonder if I should instead move this to Argument
. Make an Either ExpValSpecial Expression
type and use it in Argument
. Then the changes are limited to the call
context only, and don't muddy the AST. Thinking about it I've now become fairly certain that's better, I didn't catch that Argument
existed. Will try.
It looks like we get away with it in all parsers. I need to add some explicit tests, and think about how we handle the new case of "variable as expression" in analyses. Should be in the dataflow analysis.
Note: This introduces 2 shift/reduce conflicts in each parser (expected).
Merging the parser change & addressing behaviour (special behaviour with aliasing in certain functions) in another PR.
Targets #203 .
Based on the following tweet and referenced material
has potentially different meaning to, and should be parsed differently from
As I understand, variables may be used as expressions in two ways: either directly, as a value access, or indirectly, as an expression to be evaluated. I add a new Expression constructor for the latter, throw some hopefully-overriding parser rules in and hope for the best.
https://twitter.com/fortrantip/status/1479071485859962880