You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operator precedence is bad, it leads to bugs when the programmer and compiler disagree on precedence. However, simply saying all operators are the same precedence doesn't help since programmers can forget that.
The solution we want to use is to force the programmer to use parentheses.
The rule would be that whenever different operators were combined in an expression they would have to be grouped by parentheses. Expressions of the form:
a op1 b op2 c
would only be legal if op1 and op2 were the same operator. But:
a op1 (b op2 c)
would always be OK.
Note that different operators of the same precedence and associativity would still need parentheses, so this would be illegal:
1 + 2 - 3
To implement this the parser would allow any operator sequences, without applying any precedence and keeping parentheses information. The parse fix pass would then check for correctness.
We could leave the parentheses information in the AST, but I think it would be better for the parse fix pass to remove it. Currently this pass does not alter the AST at only, it only checks it. However I think that making it tidy up vestigial tails, only present to allow further checking, is sensible. This would also be useful for other situations, such as function body arrow omission testing.
The text was updated successfully, but these errors were encountered:
This is now complete. Precedence has been removed from infix operators for both value and type operators. See comment at the start of parser.c for details of remaining inherant precedence.
As suggest above the parse fix pass does now modify the AST, but only to remove nodes left in purely to check parsing.
Operator precedence is bad, it leads to bugs when the programmer and compiler disagree on precedence. However, simply saying all operators are the same precedence doesn't help since programmers can forget that.
The solution we want to use is to force the programmer to use parentheses.
The rule would be that whenever different operators were combined in an expression they would have to be grouped by parentheses. Expressions of the form:
a op1 b op2 c
would only be legal if op1 and op2 were the same operator. But:
a op1 (b op2 c)
would always be OK.
Note that different operators of the same precedence and associativity would still need parentheses, so this would be illegal:
1 + 2 - 3
To implement this the parser would allow any operator sequences, without applying any precedence and keeping parentheses information. The parse fix pass would then check for correctness.
We could leave the parentheses information in the AST, but I think it would be better for the parse fix pass to remove it. Currently this pass does not alter the AST at only, it only checks it. However I think that making it tidy up vestigial tails, only present to allow further checking, is sensible. This would also be useful for other situations, such as function body arrow omission testing.
The text was updated successfully, but these errors were encountered: