Parse bracketed plain vars in a function call specially e.g. call((a), a)

[raehik]

Targets #203 .

Based on the following tweet and referenced material

call double((i), i)

has potentially different meaning to, and should be parsed differently
from

call double(i, i)

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

[raehik]

@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.

[raehik]

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.

[raehik]

Note: This introduces 2 shift/reduce conflicts in each parser (expected).

[raehik]

Merging the parser change & addressing behaviour (special behaviour with aliasing in certain functions) in another PR.