Building a Simple Calculator in LISP

Because arithmetic operators in LISP are just ordinary function calls written in prefix S-expression form, such as (+ 1 2) or (* 3 (+ 4 5)), building a calculator is one of the most natural first projects in the language: you are essentially writing a function that evaluates an already-parsed S-expression tree, which is close to what the LISP reader does internally when it reads your source code. This walkthrough builds a calculator that supports the four basic operators plus nested expressions and simple error handling for cases like division by zero.

A calculator expression like 3 + 4 * 2 can be represented directly as a LISP S-expression (+ 3 (* 4 2)), where the operator is the first element (the head) and the operands follow as the rest of the list. Evaluating this structure recursively is straightforward: if the expression is a number, return it as-is; otherwise, dispatch on the operator symbol at the head of the list, recursively evaluate each operand, and apply the corresponding arithmetic function—this recursive-descent pattern mirrors exactly how LISP's own eval function processes any S-expression.

If the goal is to accept ordinary infix input like the string "3 + 4 * 2" rather than a pre-built S-expression, the calculator needs a small tokenizer and a precedence-aware parser before evaluation can happen: tokenizing splits the string into symbols like 3, +, 4, *, 2, and a recursive-descent parser then groups higher-precedence operators like * and / more tightly than + and -, producing the nested list structure (+ 3 (* 4 2)) shown earlier. This two-stage design—parse to a tree, then evaluate the tree—is the same architecture used by full-scale interpreters and compilers, just at a much smaller scale.

A production-quality calculator needs to handle division by zero, unknown operators, and malformed input gracefully rather than crashing with an unhelpful stack trace; Common Lisp's error function signals a condition that can be caught with handler-case, letting the calling code decide whether to report a friendly message, retry with different input, or propagate the failure. Testing edge cases explicitly—(calc-eval '(/ 5 0)), (calc-eval '(% 5 2)) with an undefined operator, or deeply nested expressions—during development catches bugs that simple happy-path testing would miss.