Introduction One of the easiest ways to start a compiler is to model the program as a tree of rich objects. You define a BinaryExpr, a CallExpr, a VarDecl, a WhileStmt, and so on. Each node owns references to its children. Every compiler pass gets a visitor. Each node can carry methods for pretty-printing, type information, lowering hooks, or diagnostics. It is a natural design, and for small compilers it often feels exactly right. ...
Introduction I have been writing compilers long enough to recognize my default instincts. I reach for rich AST nodes, interface-heavy abstractions, pointer-linked structures, and visitor passes because they are familiar, expressive, and great for getting a prototype off the ground quickly. What I have learned, though, is that those defaults quietly shape everything that follows. A compiler spends most of its life walking and rewriting structured data: tokens, syntax nodes, symbol tables, types, intermediate values, instructions, and diagnostics. When those representations are scattered across the heap, every later pass pays for it in locality, indirection, and complexity. Chandler Carruth makes this case directly in his CppCon 2023 talk, Modernizing Compiler Design for Carbon Toolchain, where he argues that data layout should be treated as a first-order architectural concern. Andrew Kelley’s A Practical Guide to Applying Data-Oriented Design makes the same point from the hardware side: if your access patterns fight the machine, the machine wins. ...