Introduction

So far we've looked at how to tell if text in a file corresponds to a program in some language specified by a LL or LR grammar.
Semantics concerns assigning meaning to such a program.
Meaning allows us to enforce rules of the language such as type consistency, and it also provides information needed to generate an equivalent program in an output language such as machine code.
Semantic rules are often divided into two types: static which are checked at compile time and dynamic which are checked at runtime by code output by the compiler.
The process of semantic analysis, assignment meaning to program, and intermediate code generation can be described in terms of annotation, or decoration, of a parse tree.
These annotations are known as attributes.
We begin today by talking about the semantic analyzer in more detail and discuss attribute grammars which provide a framework for the decoration of parse trees.

Semantic Analyzer

The role of the semantic analyzer is to enforce all static semantic rules and to annotate the program with information needed by the intermediate code generator.
The kinds of rules that need to be enforced vary by programming language.
For example, Lisp allows mixed-mode arithmetic and will automatically promote integers to rational to floating point or extended precision as required to maintain precision. On the other hand, Ada assigns specific types to every variable and requires explicit conversion between them in expressions.
Languages also vary in the extent to which they require implementations to perform dynamic checks. For example, C does no check except those that the underlying hardware already implements (such as division by zero). On the hand, Java performs many checks of its sandbox to try to verify that an untrusted program cannot do anything to damage the memory or files of the machine on which it is run.
Finally, how the semantic analyzer is implemented often varies from compiler to compiler. Some compilers interleave intermediate code generation with parsing (like in Yacc), others use fully separated phases. In the latter case, the semantic analyzer is passed a full parse tree of the program before it begins.
One advantage of fully interleaved phases, is one might be able to avoid having to build the parse tree or the syntax tree in its entirety.

Dynamics Checks

Many compilers that generate dynamic checks allow you to turn them on or off.
So the checks might be enabled during development and testing, but disabled for production builds.
Assertions are a popular kind of dynamic check regarding the values of program data.
An assertion is a statement that a specified condition is expected to be true when execution reaches a certain point in the code.
As an example, in Java, one can write lines like:
```
assert denominator != 0;
```
which will raise an AssertionError exception if the check fails at run time.
In C, one can write:
```
assert(denominator !=0);
```
which if it fails will cause the program to terminate with a failed assertion error.
Rust, similarly, has an assert!(condition) macro.
Some languages like Euclid, Eiffel, and Ada 2012 also have explicit support for invariants, preconditions, and postconditions.

Static Analysis

Algorithms that are used to predict run-time behavior at compile time are known as static analysis algorithms.
Such an algorithm is precise if it allows the compiler to determine whether a given program always follows the rules.
For example, type checking in Ada, ML, Rust is static and precise: the compiler ensures that no variable will ever be used at compile time in a way that is inappropriate for its type.
On the other hand, languages like Lisp, Smalltalk, Python, Ruby allow for greater flexibility, but remain type-safe by using run-time checks.
Even when a static analysis isn't precise, a compiler can often check what they can at compile time, and then generate run-time checks to check the rest dynamically. This is the approach of Java.
As one can think of the omission of unnecessary dynamic checks as a performance optimization, so one case use static analysis for code improvement.
Some examples of this are:
- Alias analysis, which determines when values can be safely cached in registers
- Escape analysis, which determines when all references to a value will be confined to a given context and so can be allocated from the stack instead of the heap
- Subtype analysis, which determines when a variable in an OO-language is guaranteed to have a certain subtype, so that its methods can be called without dynamic dispatch.
Some language in order to eliminate dynamic checks, tighten their semantic rules, banning programs for which conservative analysis fails. Here a conservative analysis is an optimization that is only applied if it can be guaranteed to be safe (always produce correct code) and effective (always improve performance).
For example, the definite assignment rules in Java, allow the compiler to ensure a variable is always given a value before it is used in an expression and so obviates needed such a check at runtime.

Quiz

Which of the following statements is true?

The keyword free is used to deallocate heap storage in Rust.
A given value in Rust can have at most one owner at a time.
All Rust projects must be in a single file.

Attribute Grammars

Recall the following LR grammar for arithmetic expressions:

E ::= E + T
E ::= E - T
E ::= T
T ::= T * F
T ::= T / F
T ::= F
F ::= - F
F ::= ( E )
F ::= const

This grammar generates all properly formed constant expression over the basic operations, but it doesn't say what they mean.
To associate a meaning, we add attributes to each of the symbols of our grammar.
For example, we can associate a val attribute to represent the value of a symbol. I.e., E.val, T.val, F.val.
We assume the val of const is provided to us by the scanner.
We then create rules (called an attribute grammar) which say how the val's from the constants propagate:

More on attribute grammars

Here is another simple attribute grammar to implement a count attribute (.c) for lists:

L ::= id LT    ⊳ L.c := 1 + LT.c
LT ::= , L     ⊳ LT.c := L.c
LT ::= ε       ⊳ LT.c := 0

Notice each semantic rule begins with a ⊳.
Notice we allow any function that may be well defined to be used in our rules. I.e., in the example of last slide, we assume, there is some well defined code for sum, difference, product. In the example above, we were a little more relaxed and sloppy and used + for the code for sum.
We also allow for a wide variety of possible attributes to associate with a symbol.
Possible attributes of attribute decorated tree nodes might include:
- For an identifier, a reference to information about it in the symbol table
- For an expression, its type
- For a statement or expression, a reference to corresponding code in the compiler's intermediate form
- For almost any construct, an indication of the file name, line, and column where the corresponding source code begins
- For any internal node, a list of semantic errors found in the subtree below

Decorating a Parse Tree According to an Attribute Grammar

The process of evaluating attributes is called annotation or decoration.
The image above show such a decoration for the expression (1+3)*2 in our first attribute grammar.
In the case of the expression example, each Symbol has at most one attribute and the values are calculated (synthesized) only in productions in which their symbols appears on the left-hand side of a rule.
For such parse trees, the attribute flow, the pattern in which information moves from node to node, is bottom up.
An attribute grammar in which all attributes are synthesized is called S-attributed.

Inherited Attributes

It is possible for attributes to have their values calculated when their symbol is on the right-hand side of the current production.
Such attributes are said to be inherited.
Inherited attributes allow contextual information to flow into a symbol from above or from the side, so that the rules of that production can be enforced in different ways according to the surrounding context.
Symbol table information is often passed as inherited attributes.
Inherited attributes from the root of the parse tree can be used to represent the external environment (command-line arguments, etc.).

Inherited Attribute Example

Consider the grammar:

expr ::= const expr_tail
expr_tail ::= - const expr_tail | ε

The expression 9 - 4 - 3 has the parse tree:
To evaluate this expression, we probably want to use some kind of left to write attribute flow, that might look like:
Such an evaluation could be implemented with attribute rules:
Here the attribute st is for subtotal calculated on the way down the tree.

Semantics

Outline