Symbol tables contain three different kinds of objects: types, symbols, and variable definitions. The entries within a symbol table may only be referenced within the corresponding scope. This includes references within registered annotations. Violating this condition may lead to strange and unexpected errors.
For simplicity, the symbol table entries are stored on lists instead of
using hash tables. In theory, the actual implementation (lists or hash
tables) should not be visible in the symbol table interface.
Unfortunately that is not completely true for the current implementation
of SUIF--the lists can be accessed directly. The types
,
symbols
, and var_defs
methods return pointers to the
lists. However, these lists should only be accessed to examine the
entries and should never be modified directly. The symbol table classes
provide other methods to add and remove entries from the lists and those
methods should always be used. If the list implementation becomes a
performance bottleneck, we may need to switch to hash tables, and code
that modifies the lists directly will be relatively hard to convert.
To distinguish the symbol tables nested within a particular scope, each
table is given a name. The name
and set_name
methods
retrieve and modify this name. If a scope in the source program has a
name associated with it, that name may be used for the corresponding
symbol table. For example, the name of a procedure-level symbol table
should generally be the same as the name of the procedure. On the other
hand, nested scopes within procedures are typically unnamed, and names
must be generated for the corresponding symbol tables.
The symbol table names are used when printing a reference to a symbol or
named type. Because the symbol or type name alone may not be sufficient
to identify it uniquely, the chain_name
method is used to
identify the symbol table. The chain name of a symbol table includes
the names of all of the symbol tables from the procedure-level downward,
separated by slashes (as in a Unix path). The file-level name is not
included since it should always be clear from the context. The chain
name for a global or file symbol table is the empty string.
Duplicate names within a symbol table should be avoided whenever
possible. Each kind of symbol has a separate name space. A variable,
for example, may have the same name as a label in the same symbol table.
Named types and child symbol table names are also in separate name
spaces. Duplicate names may be temporarily introduced but to avoid
problems they should be renamed as soon as possible. The
rename_duplicates
method is provided to check for and rename any
duplicates in a symbol table. This method is automatically called
before writing out each symbol table.