L1

Expressions are instructions, not just numbers

High school · BODMAS / PEMDAS · order of operations

What is an expression?

An expression is any combination of numbers, operators (like +, , ×, ÷), and sometimes brackets that can be evaluated to produce a single value. 2 + 2 is an expression. So is 10 ÷ (2 + 3).

Unlike an equation, an expression has no equals sign — it simply is the thing being evaluated. The calculator's job is to work through it and return one result.

Step 01
You type your expression
The calculator receives a string of characters — digits, symbols, brackets.
Step 02
It reads the order of operations
Brackets first, then powers, then × and ÷, then + and −. This is BODMAS / PEMDAS — a rule built into the calculator.
Step 03
It evaluates step by step
The calculator works through sub-expressions from the inside out until one number remains.
Step 04
It returns the result
The final number is displayed. The same input always produces the same output.
See it in action
3 + 4 × 211× is evaluated before +, so 4×2=8 first, then 3+8=11
(3 + 4) × 214Brackets change everything — (3+4)=7 is evaluated first
100 ÷ (5 × 4)5Inner bracket first: 5×4=20, then 100÷20=5
The core insight: A calculator doesn't read your expression the way you'd read a sentence. It parses it into a tree of operations, evaluates the deepest branches first, and works its way out to the root — the final answer.
L2

Parsing, tokens, and operator precedence

College · tokenisation · abstract syntax trees · functions

Tokenisation — breaking the expression apart

Before the calculator can evaluate sin(π/2) + log(100), it has to understand what each piece is. The first step is tokenisation: splitting the raw text into typed units called tokens — numbers, operators, function names, parentheses, constants.

sin(π/2) + log(100) becomes: [sin] [(] [π] [/] [2] [)] [+] [log] [(] [100] [)] — each token has a type and a value the parser knows how to handle.

Parsing — building the expression tree

Tokens are then arranged into an abstract syntax tree (AST) — a branching structure where each node is an operation and its children are the values it operates on. The tree makes order-of-operations unambiguous: deeper nodes are always evaluated first.

For 2 + 3 × 4, the tree has × at a deeper level than +, so multiplication is resolved first regardless of where it appears in the original string.

Parse
Tokenise the input
Raw text → typed tokens: numbers, operators, function names, brackets, constants like π and e.
Build
Construct the AST
Tokens arranged into a tree where precedence and associativity are encoded structurally.
Resolve
Evaluate leaf nodes first
Constants substituted (π ≈ 3.14159…), functions called with their arguments, bottom-up.
Return
Propagate to root
Results bubble up through the tree until the root node produces the final value.
College-level expressions
sin(π / 2)1π substituted, division evaluated, then sin() applied to the result
log10(1000)3"What power of 10 gives 1000?" — the calculator solves this directly
2^3 + sqrt(16)122³=8, √16=4, then 8+4=12 — exponents and roots are just functions
e^2 * cos(0)≈ 7.389e substituted, e²≈7.389, cos(0)=1, product = 7.389
Key idea: Functions like sin(), log(), and sqrt() are not special magic — the calculator treats them as nodes in the tree just like + or ×. Each takes an input and returns an output. Nesting functions just means nesting nodes deeper in the tree.
L3

Expressions in real work — formulas, variables, and live data

Workforce · spreadsheets · financial models · engineering · code

Named variables and cell references

Practical expression engines allow you to name values. In a spreadsheet, B2 * C2 * (1 - D2) isn't just arithmetic — each reference is resolved at evaluation time, pulling a live value from a cell. Change the source data, and every expression that references it is re-evaluated automatically.

This is why spreadsheet formulas are expression calculators: the engine tokenises your formula, resolves each reference to its current value, builds the operation tree, and evaluates it every time the data changes.

Type-aware evaluation

Real-world calculators handle more than numbers. Dates, currency, percentages, text — a robust expression engine knows the type of each value and applies the right operation. Multiplying a number by a percentage requires implicit conversion. The same + operator may add numbers, concatenate strings, or advance a date, depending on what it is given.

Input
Formula with references
Cell addresses, named ranges, or variable names appear alongside operators.
Resolve
Dereference at runtime
Each reference is looked up — the engine fetches the current value before evaluation begins.
Type-check
Apply type rules
The engine checks operand types and applies coercions (e.g. % → decimal) before running the operation.
Output
Formatted result
Result returned in the appropriate format — currency, percentage, date, or plain number.
Workplace expression examples
revenue * (1 - tax_rate)net incomeVariables resolved at runtime — change revenue, the result updates instantly
PMT(rate/12, term*12, -loan)monthly paymentFinancial functions — the engine evaluates each argument as a sub-expression
IF(score >= 90, "A", IF(score >= 80, "B", "C"))"A" / "B" / "C"Conditional expressions — evaluation branches based on a sub-expression's result
Why this matters at work: Understanding that every formula is an expression tree means you can debug formulas methodically — evaluate each branch in isolation, identify where the wrong value enters, and fix it at the source rather than guessing.
L4

Symbolic evaluation, lazy trees, and calculus expressions

University · symbolic computation · differentiation · SymPy / Mathematica

Numeric vs. symbolic evaluation

A numeric calculator evaluates sin(π/3) and returns 0.866025… — a floating-point approximation. A symbolic evaluator keeps the expression alive: it knows sin(π/3) = √3/2 exactly, converting to a decimal only if you explicitly ask for it.

Symbolic engines represent the entire expression tree as a first-class data structure. The tree isn't consumed by evaluation — it can be rewritten, differentiated, integrated, simplified, or factored. The same infrastructure that evaluates x² + 2x + 1 can also factor it to (x+1)².

Differentiation as tree transformation

Symbolic differentiation works by applying rules to the expression tree — not by performing numerical calculus. The derivative of a sum is the sum of derivatives, so d/dx(f + g) becomes two recursive calls on the tree's children. The product rule is another structural transformation.

This means a symbolic calculator can differentiate x³·sin(x) + e^x by traversing its tree and applying known rules at each node, without ever approximating anything numerically.

Parse
Build symbolic tree
Variables remain as symbols — x, θ, n. The tree is a data structure, not an evaluation queue.
Rewrite
Apply algebraic rules
Simplification, factoring, expansion — each is a set of rewriting rules applied until a normal form is reached.
Transform
Differentiate / integrate
Calculus operations are structural — the tree is recursively transformed using differentiation rules, producing a new tree.
Emit
Symbolic or numeric output
The result can stay symbolic (exact form) or be evaluated numerically at a specific value of x.
Symbolic expression examples
d/dx [ x³ · sin(x) ]3x²sin(x) + x³cos(x)Product rule applied structurally to the AST — exact, no approximation
∫ 2x dxx² + CAnti-differentiation rule applied to the power node in the tree
simplify( (x²−1) / (x−1) )x + 1Algebraic rewriting: factor numerator, cancel common term — pure tree manipulation
The leap: Once expressions are first-class data structures rather than evaluation pipelines, a calculator becomes a reasoning system. The same engine that computes an answer can prove equivalences, find critical points, and solve systems of equations — all by manipulating trees.
L5

Formal grammars, lambda calculus, and computation as expression

Research mathematics · lambda calculus · Curry-Howard · proof assistants

Formal grammars and the parser's foundations

Every expression calculator is defined by a formal grammar — typically a context-free grammar specified in Backus-Naur Form (BNF). The grammar defines exactly which strings are valid expressions and how they parse into trees. The grammar for arithmetic expressions is recursive: an expression can contain sub-expressions, which can contain sub-expressions, allowing arbitrary nesting of brackets and functions.

Lambda calculus — expressions all the way down

Lambda calculus reduces computation to a single type of expression: the lambda abstraction. λx. x + 1 is a function that takes x and returns x+1. Application of one expression to another — (λx. x²)(5) — is evaluation by substitution. Every computable function can be expressed this way.

Modern functional languages (Haskell, Lean, Coq) are essentially elaborated lambda calculi. Their interpreters are expression evaluators — reduction engines that repeatedly apply substitution rules until no further reduction is possible. Evaluating an expression and executing a program are the same operation.

The Curry-Howard correspondence

Propositions in logic correspond exactly to types in a programming language, and proofs correspond exactly to programs (expressions). To prove a theorem is to construct an expression of the correct type. A proof assistant like Coq or Lean is simultaneously a theorem prover and an expression calculator — every proof is a term, and type-checking a proof is evaluating whether an expression is well-typed.

Formal expression examples
λx. λy. x + yℤ → ℤ → ℤA curried addition function — type inferred by the evaluator
(λx. x²)(λy. y+1)(3)16Beta reduction: (3+1)² — substitution repeated until normal form is reached
fix (λf. λn. if n=0 then 1 else n·f(n−1))n!The Y-combinator encodes recursion as a fixed-point expression — no named function needed
⊢ A → (B → A)λp:A. λq:B. pProof-as-expression: the term that inhabits this type, verifying the proposition
The full circle: A student types 3 + 4 × 2 and gets 11. A research mathematician writes λp:A. λq:B. p and verifies a logical theorem. Both are using an expression calculator. The tree is the same structure. The evaluation is the same process. Only the language — and the depth — has changed.