Currently, our expressions generate parenthesis defensively in their "toString()" method, to avoid context checking. While this generates syntactically correct expression strings, they are not very human-readable. E.g.:
Exp.parse("a = $1 and b = $2 or not d = 'a'").toString();
// produces the following String:
// (((a) = ($1)) and ((b) = ($2))) or (not ((d) = ('a')))
Ideally Exp.toString() should be aware of expression associativity (operator precedence) rules as defined in the grammar, and only add the needed parenthesis, but for now we can go after a low-hanging fruit - remove parenthethis around simple expressions like paths, parameters and scalars. So the expression above should produce smth like this, which is already way more readable:
Currently, our expressions generate parenthesis defensively in their "toString()" method, to avoid context checking. While this generates syntactically correct expression strings, they are not very human-readable. E.g.:
Ideally
Exp.toString()should be aware of expression associativity (operator precedence) rules as defined in the grammar, and only add the needed parenthesis, but for now we can go after a low-hanging fruit - remove parenthethis around simple expressions like paths, parameters and scalars. So the expression above should produce smth like this, which is already way more readable: