Checking beyond grammatical form
An expression can be grammatically valid while using an undefined variable or an invalid type combination. Semantic analysis distinguishes the structure of a construct from whether the language permits it.
Static type checking is central in many languages, but the rules vary. Analysis can additionally record expression types, declaration relationships, and layout information required by later compilation stages.
References: [1]
Names need an environment
An identifier node needs context: which declarations are visible and what types they have. Symbol tables or equivalent environments maintain these associations as traversal enters and leaves scopes.
Cornell compares stacks of hash tables, persistent search trees, and hash tables with update logs. They can express related environments with different lookup, restoration, and retention costs. The semantic rule and its data-structure implementation remain distinct.
References: [1]
Checked conditions do not cover every error
Analysis can decorate AST nodes with types or store information in separate structures. Successful completion establishes the conditions actually checked by that stage.
File availability, input-dependent bounds, and intended business outcomes can still depend on execution or further analysis. Absence of reported static semantic errors is not absence of every possible failure, and programming-language semantics does not capture all meanings of natural-language intent.