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

Arithmetic operator precedence rules #33

Merged
merged 1 commit into from Nov 15, 2016

Conversation

@apparentlymart
Copy link
Member

apparentlymart commented Nov 15, 2016

Previously all operators had equal precedence and they were all parsed in a left-associative manner. This was a simple rule, but it was counter-intuitive to people familiar with conventional expression notation or other languages with precedence rules.

Here we give multiplication and division higher precedence than addition and subtraction, so that e.g. 1+2*3 will parse as 1+(2*3) rather than (1+2)*3 as before. This is a breaking change for anyone that was depending on the old left-associative parsing behavior, but I assume that this will be relatively few people simply because the old behavior was so counter-intuitive that users are likely to have used explicit parentheses to make their code understandable.

This implementation just uses the standard Go stack to keep track of the nested parsing states required to process the levels of precedence. With only two levels of precedence this is a no-brainer, and this approach should suffice for any reasonable number of levels of precedence.

This is one of the follow-on changes I proposed in #32, and (if included into Terraform) resolves hashicorp/terraform#9169. I chose to attack this one of the proposals first because I figured that if it will be included into Terraform 0.8 it should be included in as many betas and release candidates as possible to give people warning and the opportunity to test existing configs that have non-trivial arithmetic expressions.

Previously all operators had equal precedence and they were all parsed in
a left-associative manner. This was a simple rule, but it was
counter-intuitive to people familiar with conventional expression notation
or other languages with precedence rules.

Here we give multiplication and division higher precedence than addition
and subtraction, so that e.g. 1+2*3 will parse as 1+(2*3) rather than
(1+2)*3 as before. This is a breaking change for anyone that was depending
on the old left-associative parsing behavior, but we assume that this will
be relatively few people simply because the old behavior was so
counter-intuitive that users are likely to have used explicit parentheses
to make their code understandable.

This implementation just uses the standard Go stack to keep track of the
nested parsing states required to process the levels of precedence. With
only two levels of precedence this is a no-brainer, and this approach
should suffice for any reasonable number of levels of precedence.
@mitchellh

This comment has been minimized.

Copy link
Member

mitchellh commented Nov 15, 2016

LGTM

@mitchellh mitchellh merged commit 6861984 into hashicorp:master Nov 15, 2016
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

2 participants
You can’t perform that action at this time.