The code for parsing cond conditions was written in a quite messy way, and it's gained a lot of functionality over time, leading to unintuitive and messy code. I'd like to rewrite it, with readability and simplicity in mind.
I also want the new parser to have near-symmetric handling of the LHS and RHS of comparisons. var:, ?, cvar:, and % will all work on both sides of an equation, meaning they can be dealt with at the tokenizer level; the only thing which will be handled differently is literals (e.g. map), which on the LHS are special names and on the RHS are equivalent to strings (i.e. foo is the same as %foo). This can be handled at the parser level with no problem, since the tokenizer doesn't need to identify the specific LHS options (map etc). The Condition struct should look like this:
The code for parsing
cond
conditions was written in a quite messy way, and it's gained a lot of functionality over time, leading to unintuitive and messy code. I'd like to rewrite it, with readability and simplicity in mind.I also want the new parser to have near-symmetric handling of the LHS and RHS of comparisons.
var:
,?
,cvar:
, and%
will all work on both sides of an equation, meaning they can be dealt with at the tokenizer level; the only thing which will be handled differently is literals (e.g.map
), which on the LHS are special names and on the RHS are equivalent to strings (i.e.foo
is the same as%foo
). This can be handled at the parser level with no problem, since the tokenizer doesn't need to identify the specific LHS options (map
etc). TheCondition
struct should look like this: