When a construct both denotes a value and performs an effect, what does nesting it inside a larger expression cost?

## Two properties, often confused for one Two separate questions can be asked of any construct: 1. **Does it denote a value?** If yes, it is an expression and can be nested. 2. **Does it perform an effect?** If yes, running it changes something observable — state, control flow, the outside world. These are independent. A construct can denote a value and do nothing else; it can perform an effect and denote nothing; and it can do **both**. The third combination is where trouble lives, because the first property grants it entry to places the second makes it unwelcome. A candidate who has learned that "expressions compose" sometimes hears this as "if I make everything an expression, my code composes". Expression-orientation removes one obstacle — the form now has a value to pass around — but it says nothing about whether reading that value in place is safe. ## What nesting quietly assumes When you drop a sub-expression into a larger one, you lean on assumptions you rarely say out loud: - that the sub-expression can be understood on its own, from its value; - that moving it — into a name above, into a different operand position — leaves the program's behaviour alone; - that it is evaluated exactly once, when the enclosing form is evaluated. A form that also acts breaks all three. Understanding it now requires knowing what it does as well as what it yields. Moving it moves the effect. And the third assumption is the sharpest: enclosing forms are not obliged to evaluate every part they contain. An operator that decides its result from one side alone may never evaluate the other, and a choice evaluates only the arm it selects — so the effect fires or does not depending on a sibling's value. ## The rubric case ```pseudocode // the condition records the attempt AND yields a count if recordAttempt(student, score) > retryLimit then flag(student) end // the effect is its own step; the condition only reads a value constant attempts = recordAttempt(student, score) if attempts > retryLimit then flag(student) end ``` Both shapes record the attempt and both flag the same students. The difference is what a reviewer has to do to find the write. In the first, the write is inside a test — a position where a reader expects a question to be asked, not an answer to be filed. Put that condition behind an operator that may skip its right side, or into an arm of a larger choice, and whether the attempt is recorded at all becomes a property of code written somewhere else. The second shape says the same thing in two lines and keeps each construct to one job: the call acts and yields, its result is bound, and the condition reads a name. Nothing is hidden. ## The assignment case The sharpest version appears where **assignment itself denotes a value**. In such a design `band = bandFor(score)` is not only a write; the whole thing evaluates to something and can therefore be nested — inside a condition, inside a call argument, inside another assignment. The shape is famous for two failure modes: a comparison mistyped as an assignment reads as a perfectly valid condition that also rewrites the name it was meant to test, and a chain of nested assignments makes the order in which names are updated depend on the evaluation rules of the enclosing operators. Languages differ in whether they allow this at all — some make assignment a statement precisely to close the door, some allow it and warn, some allow it freely — which is itself the tell that it is a design trade-off rather than an oversight. ## How to judge it in review | the construct | safe to nest? | why | |---|---|---| | denotes a value, no effect | yes | reading it in place tells the whole story | | performs an effect, denotes nothing | cannot nest | there is no value to consume | | denotes a value and writes state | with care | the write moves with the sub-expression | | denotes a value and transfers control | rarely | the enclosing form may never finish evaluating | The working rule is short: **one job per position**. Let the acting construct have its own line and its own name; let the expression that reads the name stay readable as a value. This costs a line and buys a reviewer the ability to find every write by scanning the left edge of the code rather than the interior of every condition. ## Why this is a senior question Juniors are taught that expressions are the tidier form, and they are usually right. The experienced version of the judgement is that the tidiness is only real when the nested parts can be read for their values — and that a codebase which nests acting constructs has made itself *harder* to review than the statement-shaped version it replaced, while looking more modern. Being able to say where the line sits, and to fix a case by lifting the effect out rather than by abandoning expressions, is what separates the two answers.