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

Variadic addition and multiplication #415

Open
hudlow opened this issue Nov 27, 2024 · 0 comments
Open

Variadic addition and multiplication #415

hudlow opened this issue Nov 27, 2024 · 0 comments

Comments

@hudlow
Copy link
Contributor

hudlow commented Nov 27, 2024

Even assuming that all subexpressions are without side effects, sequences of addition (and subtraction) or multiplication (and addition) are order-sensitive and therefore cannot be safely balanced1. As a consequence, protobuf nesting limits result in a hard cap for the number of terms in a mathematical expressions and this cap also interacts with other structures such as nested parentheticals, function calls, and list/map/message construction. To get more control over #410 (in particular, to cap the number of terms in a mathematical expression consistently, without respect to other structures in the expression), I'd like to see support for variadic addition and multiplication2.

Is this feasible? I am a little shaky on what the commitment to forward- and backward-compatibility is for the current AST definition, though I assume forward compatibility of existing evaluators is not a hard requirement, given the in-progress updates to comprehensions.

Footnotes

  1. For example, 1e16 + -1e16 + 1.0 does not equal 1e16 + 1.0 + -1e16 and 1 + -1 + 9223372036854775807 does not equal 1 + 9223372036854775807 + -1 (the latter producing an overflow error).

  2. Because subtraction and division share precedence with addition and multiplication, respectively, there would need to be a single variadic function for addition and subtraction and a single variadic function for multiplication and division — otherwise, alternating the same-precedent operations would again produce a deep expression that could not be safely rebalanced.

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