= Abstract syntax tree
{title2=AST}
{wiki}
= AST
{c}
{synonym}
An <abstract syntax tree> is a <rooted tree> recording the meaningful syntactic pieces of a program and how they fit together. A <program identifier> such as `x`, a <literal value> such as `2`, and a node representing <addition> have different roles. Their arrangement answers structural questions: which <program expression> supplies an operand, which name is a <variable assignment> target, and which construct encloses another. This makes an <abstract syntax tree> useful to a <compiler>, an <interpreter>, and the <type system> that checks a program.
The word "abstract" describes what is omitted. <Lexical analysis> first recognizes <lexical tokens>, such as `x`, `=`, `2`, `+`, `3`, `*`, `4`. A concrete <parse tree> can retain <grammar derivation> structure, including punctuation and intermediate <context-free grammar> categories such as expression, term and factor. An <abstract syntax tree> usually keeps the operation and its operands without all those grammar scaffolds. Parentheses can determine its shape without surviving as separate nodes. A <parser> may construct the <abstract syntax tree> directly; it need not first allocate a concrete <parse tree>.
An <abstract syntax tree> records <programming language syntax>, but does not by itself supply all <programming language semantics>. In `a+b`, the names do not reveal their current values, and `+` might perform <addition> of <integers> or concatenate strings. The <programming language> rules, name bindings, and operand types determine the meaning. In <Python>, successfully calling `ast.parse` also does not guarantee that later <compilation> will accept the result: parsing `return 42` succeeds, but compiling that statement outside a function fails. <Python 3.14 documentation/ast — Abstract syntax trees, Python 3.14 documentation>[ast.parse: parsing performs no scoping checks; the return 42 example]{ref}
An <abstract syntax tree> is not <machine code>. Its nodes describe language constructs. A <compiler> can check and transform this structure before translating it into executable instructions; an <interpreter> can evaluate an appropriate tree directly. The little evaluator below demonstrates this distinction without pretending to implement an entire <programming language>.
Back to article page
