In a stack-based postfix evaluator, why must the first value popped be the right operand?

## Postfix, and why it exists In postfix (reverse Polish) notation each operator follows its operands: `a b -` means a minus b, and `a b - c *` means `(a - b) * c`. The point of the notation is that it carries no parentheses and needs no precedence rules — the position of each operator already says exactly which values it consumes. That makes evaluation a single left-to-right scan with one stack, which is why formula engines, calculators and many bytecode machines evaluate in this form even when users type ordinary infix. Precedence and associativity are not gone; they were **resolved earlier**, during the conversion from infix to postfix. The evaluator inherits those decisions and must not undo them — and popping operands in the wrong order is exactly how it undoes them. ## The evaluation loop Scan the token sequence once: - **Number** — push it. - **Binary operator** — pop once into the right operand, pop again into the left operand, compute, push the result. - **End** — the single remaining value is the answer. The pop order falls straight out of LIFO. The operands were pushed in reading order, left then right, so the right operand is on top. Popping it first and the left operand second is not a convention you could flip; it is forced by the order the values arrived. ## Why the bug is so quiet Suppose someone writes the two pops the other way round. For addition and multiplication nothing happens — those operators are commutative, so swapping the arguments cannot change the result. A test suite built from sums and products passes completely. The failure only surfaces on subtraction, division, exponentiation, modulo, string concatenation, date differences, and any other non-commutative operation. Trace a spreadsheet formula that computes takehome as `(gross - fee) * rate`, in postfix `gross fee - rate *`, with gross = 120.00, fee = 45.50, rate = 0.9. Correct evaluation: push 120.00, push 45.50; on `-` pop 45.50 as right, pop 120.00 as left, compute 74.50, push it; push 0.9; on `*` pop 0.9, pop 74.50, compute **67.05**. Swapped pops: on `-` the operands become 45.50 minus 120.00 = -74.50, and the multiplication (being commutative) faithfully preserves the error to **-67.05**. The sign flip is the whole answer, and on a division the analogous bug returns a reciprocal — a rate of 0.9 becomes about 1.11 — which looks plausible enough to reach a report before anyone notices. This is why a review of an expression evaluator should ask for one test with a non-commutative operator and unequal operands. `9 4 -` must be 5, never -5; `9 3 /` must be 3, never one third. Equal operands are useless here: `4 4 -` is zero under both orders. ## The validation invariants A correct evaluator enforces two arity rules that candidates routinely skip: 1. **Underflow** — if a binary operator arrives with fewer than two values on the stack, the expression is malformed (`3 +`). Report it rather than reading past the bottom. 2. **Leftover** — when the scan ends, exactly one value must remain. Two or more means operands were never consumed (`3 4 5 +`), zero means there were no operands at all. Together these turn the evaluator into a cheap validator: a token sequence is well formed exactly when the running stack size never dips below the operator's arity and finishes at one. ## Unary operators and other traps Negation is the classic ambiguity. If unary minus and binary minus share a token, the evaluator cannot tell how many values to pop, and `5 3 -` becomes indistinguishable from a negation applied twice. The fix is upstream: emit a distinct token for unary negation during conversion, and let the evaluator pop one operand for it. The same reasoning generalises to n-ary functions — the token must carry its arity, or the stack cannot tell where the argument list starts. For a money-handling engine two more rules apply on top of the stack logic. Amounts should be evaluated in minor units or a decimal representation rather than binary floating point, so that repeated additions do not drift by fractions of a cent, and division needs an explicit rounding decision rather than whatever truncation happens to fall out. Neither is a stack question, but both live in the same function and both surface in a design discussion about a formula engine. ## What to say in the interview Name the rule (first pop is the right operand), name why (push order plus LIFO), name the reason it hides (commutativity masks it in the operators most tests use), and name the two arity invariants. That is a complete answer, and it demonstrates the habit the question is really probing: knowing which bugs your test data cannot catch.