A Simple Compiler - Crafting a Compiler - page 48

Symbol Type Symbol Type Symbol Type

a integer k null t null

b float l null u null

c null m null v null

d null n null w null

e null o null x null

g null q null y null

h null r null z null

j null s null

Figure 2.11: Symbol table for the ac program from Figure 2.4.

table. This can be arranged by having nodes such as floatdcl and intdcl imple-
ment an interface (or inherit from an empty class) called SymDeclaring,which
implements a method to return the declared identifier's type. In Figure 2.10,
visit

(SymDeclaring n )showsthecodetobeappliedatnodesthatdeclare
symbols. As declarations are discovered, E checks that the given

identifier has not been previously declared. Figure 2.11 shows the symbol
table constructed for our example ac program.

nter S ymbol

2.7.2 Type Checking

The ac language o ers only two types, integer and float, and all identifiers

must be type-declared in a program before they can be used. After the symbol
table has been constructed, the declared type of each identifier is known, and
the executable statements of the program can be checked for type consistency.
Most programming language specifications include a type hierarchy that
compares the language's types in terms of their generality. Our ac language
follows in the tradition of Java, C, and C

ff

,inwhichafloat type is considered
wider (i.e., more general) than an integer. This is because every integer can be
represented as a float. On the other hand, narrowing a float to an integer loses
precision for some float values.
Most languages allow automatic widening of type, so an integer can be
converted to a float without the programmer having to specify this conver-
sion explicitly. On the other hand, a float cannot become an integer in most
languages unless the programmer explicitly calls for this conversion.
Once symbol type information has been gathered, ac's executable state-
ments can be examined for consistency of type usage. This process, known as
type checking , walks the AST bottom-up, from its leaves toward its root. At
each node, the appropriate visitor method (if any) in Figure 2.12 is applied:

++