an abstract syntax tree

A parse tree records every detail of how the grammar matched the input, including punctuation and bookkeeping that exist only to guide parsing. An abstract syntax tree (AST) is the cleaned-up version: it keeps the essential structure, what operation is applied to what, and throws away the noise. Think of the parse tree as the literal transcript of a meeting and the AST as the tidy minutes that record only the decisions.

Compare the two for 2 + 3 * 4. A concrete parse tree, following a grammar like E -> E + T, T -> T * F, F -> num, has chains of single-child nodes (E to T to F) and explicit nodes for the operator tokens, much of it just artifacts of how the grammar was written to control precedence. The corresponding AST is far simpler: a Plus node whose children are the number 2 and a Times node, whose children are the numbers 3 and 4. The parentheses, the helper nonterminals, and the redundant chains are gone; what remains is exactly the meaning, an addition of 2 and a multiplication, with the multiplication nested inside because it binds tighter. Parser generators build the AST through semantic actions attached to grammar rules, so the AST is constructed as parsing reduces each handle.

The AST matters because it is the data structure the rest of the compiler actually works on: type checking, optimization, and code generation walk the AST, not the verbose parse tree or the raw text. By discarding syntax that carries no meaning, the AST lets later stages reason about the program's intent directly. It is the clean handoff from the front end's parsing job to everything that comes after, and the same idea reappears far beyond compilers, in interpreters, linters, formatters, and source-to-source translators.