Introduction to

Compiler Design
Torben Ægidius
Mogensen
 Scopes and Symbol
Tables

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Scopes and Symbol Tables
 The declaration of a name has a limited scope: a
portion of the program where the name will be
visible. Such declarations are called local
declarations, whereas a declaration that makes
the declared name visible in the entire program is
called global

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Binding
 Binding Concepts

 Objects in Programming

 Binding & Compilation

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Symbol Tables
 A symbol table is a table that binds names to information. We need a number
of operations on symbol tables to accomplish this:
 We need an empty symbol table, in which no name is defined.
 We need to be able to bind a name to a piece of information. In case the name
is already defined in the symbol table, the new binding takes precedence over
the old.
 We need to be able to look up a name in a symbol table to find the information
the name is bound to. If the name is not defined in the symbol table, we need
to be told that.
 We need to be able to enter a new scope.
 We need to be able to exit a scope, reestablishing the symbol table to what it
was before the scope was entered.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Implementation of Symbol Tables

 There are many ways to implement symbol tables,

but the most important distinction between these
is how scopes are handled.

 This may be done using a persistent (or functional) data

structure, or it may be done using an imperative (or
destructively updated) data structure.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Persistent Mechanism

 A persistent data structure has the property that no

operation on the structure will destroy it. Conceptually, a
new modified copy is made of the data structure whenever
an operation updates it, hence preserving the old structure
unchanged

 This means that it is trivial to reestablish the old symbol

table when exiting a scope, as it has been preserved by
the persistent nature of the data structure. In practice, only
a small portion of the data structure is copied when a
symbol table is updated, most is shared with the previous
version.
Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Imperative Approach

 In the imperative approach, only one copy of the symbol

table exists, so explicit actions are required to store the
information needed to restore the symbol table to a
previous state.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Persistent Symbol Tables

LIST BASED
Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Persistent Symbol Tables (continued…)

 When a new element is added to the front of a list or an

element is taken off the front of the list, the old list still
exists and can be used elsewhere

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Persistent Symbol Tables (continued…)

 empty: An empty symbol table is an empty list.

 bind: A new binding (name/information pair) is added
(consed) to the front of the list.
 lookup: The list is searched until a pair with a matching
name is found. The information paired with the name is
then returned. If the end of the list is reached, an indication
that this happened is returned instead. This indication can
be made by raising an exception or by letting the lookup
function return a special value representing “not found”.
This requires a type that can hold both normal information
and this special value, i.e., a sum-type.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Persistent Symbol Tables (continued…)

 enter: The old list is remembered, i.e., a reference is made

to it.
 exit: The old list is recalled, i.e., the above reference is
used.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Imperative Symbol Table

STACK
BASED

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Imperative Symbol Table (continued…)

 A simple imperative symbol table can be implemented as a

stack, (which works in a way similar to the list-based
functional implementation in terms of end result however
different in terms of working i.e. stack/PDAs are
destructive and list is persistent)

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Simple Imperative Symbol Table (continued…)

 empty: An empty symbol table is an empty stack.

 bind: A new binding (name/information pair) is pushed on
top of the stack.
 lookup: The stack is searched top-to-bottom until a
matching name is found. The information paired with the
name is then returned. If the bottom of the stack is
reached, we instead return an error-indication.
 enter: We push a marker on the top of the stack.
 exit: We pop bindings from the stack until a marker is
found. This is also popped from the stack.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Efficiency Issues

 *Efficiency issues depend on the programming

implementation of the compiler and best practices in data
structures may be followed; however it is out of the scope
of this course and the current text *[1]
 For Example, hashing is a better approach to be followed
rather than sequential search in resolving binding issues in
symbol tables.


* [1] Coding the theoretical designed model is out of the scope of this course. Students may at PG level will find it
useful. Interested students may consult TAs for details and PG level courses.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Shared or Separate Name Spaces

 In some languages (like Pascal) a variable and a function

in the same scope may have the same name, as the
context of use will make it clear whether a variable or a
function is used. We say that functions and variables have
separate name spaces, which means that defining a name
in one space doesn’t affect the same name in the other
space.

 On the other side, some languages have a shared name

space for variables and functions.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;
Shared or Separate Name Spaces (continued…)

 Name spaces may be shared or separate for all the kinds

of names that can appear in a program, e.g., variables,
functions, types, exceptions, constructors, classes, field
selectors etc. Which name spaces are shared is language-
dependent.

 Separate name spaces are easily implemented using one

symbol table per name space, whereas shared name
spaces naturally share a single symbol table. However, it
is sometimes convenient to use a single symbol table even
if there are separate name spaces.

Course: Introduction to Compiler Design & Construction (Level: UG) Copyright© 2011
Professor Mogensen, University of Copenhagen, Denmark; Dexter Kozen, Cornell University,
Ithaca, USA;