Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove operator precedence #32

Closed
andymcn opened this issue Sep 11, 2014 · 1 comment
Closed

Remove operator precedence #32

andymcn opened this issue Sep 11, 2014 · 1 comment
Assignees

Comments

@andymcn
Copy link
Contributor

andymcn commented Sep 11, 2014

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.

@andymcn andymcn self-assigned this Sep 11, 2014
@andymcn
Copy link
Contributor Author

andymcn commented Sep 17, 2014

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.

@andymcn andymcn closed this as completed Sep 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant