When is a precedence-climbing binding-power table worth adopting for a formula evaluator whose users request a new operator every quarter, and what does it cost?

## The two shapes, priced Both designs parse the same expressions when the binding powers reproduce the layering, so the decision is about cost of change, not capability. | dimension | layered expression rules | binding-power table | |---|---|---| | adding an operator at an existing level | one line in one function | one row | | adding a new precedence level | a new function plus an edit to its neighbour | one row, using a gap in the numbering | | calls per operand parsed | one per level | one | | where precedence is readable | the shape of the code | a table of numbers | | precedence decided at run time | not without regenerating the parser | possible, since it is data | | review surface of a change | control flow | data | The row that usually decides it is the last one. A change to a table row is reviewable by someone who does not know the parser; a change to a chain of mutually calling functions is not. ## When the table earns its place - **The operator set grows on someone else's schedule.** A formula evaluator behind a reporting tool's calculated columns is the archetype: every quarter a user wants one more operator, and each addition to a layered parser touches working code that already has behaviour people depend on. - **Precedence must be configurable or extensible.** If operators can be contributed rather than hard-coded, the layered design cannot express that at all without rebuilding the parser, because precedence is the shape of the code. - **The level count is large.** Fifteen to twenty levels means fifteen to twenty frames on every operand, which shows up in parse-heavy work such as re-parsing a large saved workbook of formulas on load. - **Several surfaces share one expression language.** One loop plus one table is easier to keep in step across a validator, an evaluator and a formatter than one chain of functions copied into each. ## When the layers are fine - **The operator set is small and closed.** Four or five levels that have not changed in years cost nothing to maintain, and the explicitness is a genuine asset for an occasional maintainer. - **The grammar is the published artefact.** If the rule set is what you hand to users or to another team as the specification, keeping the code shaped like it removes a translation step and a class of drift. - **Nobody on the team has met this technique.** A parser that the team cannot confidently modify is a worse outcome than a few redundant functions, and this argument is weaker than it sounds only because the loop is small enough to learn in an afternoon. ## What you give up 1. **Legibility.** The precedence order stops being visible in the code. It must be written down deliberately, in a table ordered by power with associativity noted per row, and that document has to be kept truthful. 2. **Slack in the numbering.** Because left-associative operators consume one unit above their level, consecutive numbering leaves no room to insert a level later. Gaps of ten are the usual convention. 3. **A specific failure mode.** Nearly every mistake in this design is a wrong number, and a wrong number yields an accepted parse with a different tree. The parser does not complain; the values do. ## Migrating without breaking stored formulas 1. **Derive the numbers from the existing layers.** Number the levels from the loosest upward with gaps of ten, give each left-associative operator a right power one above its left power, and equal powers to the right-associative ones. 2. **Differential-test over the real corpus.** Run both parsers across every stored formula and compare trees, not just values — equal values on today's data can hide a reassociation that differs on tomorrow's. 3. **Treat any difference as a defect in the numbers**, not as an improvement, until someone decides otherwise deliberately. A change in how an existing formula groups is a change in what users' saved work computes. 4. **Publish the precedence table** at the point of cutover, since it is now the only place the answer lives. ## The judgment The question a lead actually answers is not which parser is better but **how often precedence changes and who changes it**. If the answer is rarely and only us, layered rules are honest and cheap. If it is often, or by people outside the team, precedence is data in everything but representation, and the table simply admits that. The cost of admitting it is one afternoon of migration plus a permanent documentation obligation; the cost of not admitting it is paid a little at a time, on every request for one more operator.