1. Chap. 8, Declaration Processing and Symbol Tables J. H. Wang Dec. 13, 2011

2. Outline Constructing a Symbol Table Block-Structured Languages and Scopes Basic Implementation Techniques Advanced Features Declaration Processing Fundamentals Variable and Type Declarations Class and Method Declarations An Introduction to Type Checking

3. Constructing a Symbol Table We walk (make a pass over) the AST for two purposes –To process symbol declarations –To connect each symbol reference with its declaration An AST node is enriched with a reference to the name’s entry in the symbol table

5. Static Scoping Static scope: includes its defining block as well as any contained blocks that do not contain a declaration for the identifier Global scope: a name space shared by all compilation units Scopes might be opened and closed by braces ({ } as in C and Java), or by reserved keywords ( begin and end as in Ada, Algol)

6. A Symbol Table Interface Methods –OpenScope() –CloseScope() –EnterSymbol(name, type) –RetreiveSymbol(name) –DeclaredLocally(name) Ex. –(Fig. 8.2) Code to build the symbol table for the AST in Fig. 8.1

8. Block-Structured Languages and Scopes Block-structured languages: languages that allow nested name scopes –Concepts introduced by Algol 60 Handling Scopes – Current scope: the innermost context – Open scopes (or currently active scopes): the current scope and its surrounding scopes – Closed scopes: all other scopes

9. Some common visibility rules –Accessible names are those in the current scope and in all other open scopes –If a name is declared in more than one scope, then a reference to the name is resolved to the innermost declaration –New declarations can be made only in the current scope Global scope –Extern: in C –Public static: in Java

10. Compilation-unit scope: in C and C++ –Declared outside of all methods Package-level scope: in Java Every function definition is available in the global scope, unless it has static attribute In C++ and Java, names declared within a class are available to all methods in the class –Protected members are available to the class’s subclasses Names declared within a statement-block are available to all contained blocks, unless it’s redeclared in an inner scope

11. One Symbol Table or Many? Two common approaches to implementing block-structured symbol tables –A symbol table associated with each scope –Or a single, global table

12. An Individual Table for Each Scope Because name scope are opened and closed in a last-in first-out (LIFO) manner, a stack is an appropriate data structure for a search –The innermost scope appears at the top of stack –OpenScope(): pushes a new symbol table –CloseScope(): pop –(Fig. 8.3) Disadvantage –Need to search a name in a number of symbol tables –Cost depending on the number of nonlocal references and the depth of nesting

14. One Symbol Table All names in the same table –Uniquely identified by the scope name or depth RetrieveSymbol() need not chain through scope tables to locate a name More details in Sec.8.3.3 –(Fig. 8.8)

16. Basic Implementation Techniques Entering and Finding Names The Name Space An Efficient Symbol Table Implementation

17. Entering and Finding Names Examine the time needed to insert symbols, retrieve symbols, and maintain scopes –In particular, we pay attention to the cost of retrieving symbols –Names can be declared no more than once in each scope, but typically referenced multiple times Various approaches –Unordered list –Ordered list –Binary search trees –Balanced trees –Hash tables

18. Unordered List Simplest –Array –Linked list or resizable array All symbols in a given scope appear adjacently –Insertion: fast –Retrieval: linear scan Impractically slow

19. Ordered List Binary search: O(log n) –How to organize the ordered lists for a name in multiple scopes? An ordered list of stacks (Fig. 8.4) –RetrieveSymbols() locates stacks using binary search –CloseScope() examines each stack and pops those stacks whose top symbol is declared in the abandoned scope To avoid such checking, we maintain a separate linking of symbol table entries that are declared at the same scope level (Sec.8.3.3) Fast retrieval, but expensive insertion –Advantageous when the space of symbols is known Reserved keywords

21. Binary Search Trees Insert, search: O(log n), given random inputs –Average-case performance does not necessarily hold for symbol tables –Programmers do not choose identifiers at random! Advantage –Simple, widely known implementation

22. Balanced Trees The worst-case scenario for binary trees can be avoided if the tree is balanced –E.g.: red-black trees, splay trees –Insert, search: O(log n)

23. Hash Tables Most common, due to its excellent performance –Insert, search: O(1), given A sufficiently large table A good hash function Appropriate collision-handling techniques –(Sec.8.3.3)

24. The Name Space Properties to consider –The name of a symbol does not change during compilation –Symbol names persist throughout compilation –Great variance in the length of identifier names –Unless an ordered list is maintained, comparisons of symbol names involve only equality and inequality In favor of one logical name space (Fig. 8.5)

25. Names are inserted, but never deleted Two fields –Origin –Length

26. An Efficient Symbol Table Implementation A symbol table entry containing –Name –Type –Hash –Var –Level –Depth

27. Two index structures –Hash table –Scope display Symbols at the same level –(Fig. 8.7) & (Fig. 8.8)

30. Advanced Features Extensions of the simple symbol table framework to accommodate advanced features of modern programming languages –Name augmentation (overloading) –Name hiding and promotion –Modification of search rules

31. Records and Typenames Aggregate data structures –struct, record E.g. a.b.c.d –C, Ada, Pascal: completely specifying the containers and the field –COBOL, PL/I: intermediate containers can be omitted if the reference can be unambiguously resolved »a.c, c.d: more difficult to read Can be nested arbitrarily deeply –Tree typedef: alias for a type –Symbol table

32. Overloading and Type Hierarchies Method overloading allowed in object-oriented languages such as C++ and Java –If each definition has a unique type signature Number and types of the parameters and return type –E.g.: print(int), print(String) –To view a method definition not only in terms of its names but also its type signature To encode type signature of a method along with its name –E.g.: M(int): void To record a method along with a list of its overloaded definitions

33. Operator overloading: allowed in C++, Ada Ada allows literals to be overloaded –E.g.: diamond in two different enumeration types: as a playing card, and as a gem Pascal, Fortran allow the same symbol to represent the invocation of a method and the value of the method’s result –Two entries in the symbol table C: the same name as a local variable, a struct name, and a label

34. –E.g.: (in Ex. 17) main() { struct xxx { int a, b; } c; int xxx; xxx: c.a = 1; } Type extension through subclassing allowed in Java, C++ –resize(Shape) vs. resize(Rectangle)

35. Implicit Declarations In some languages, the appearance of a name in a certain context serves to declare the name as well –E.g.: labels in C –In Fortran: inferred from the identifier’s first letter –In Ada: an index is implicitly declared to be of the same type as the range specifier –A new scope is opened for the loop so that the loop index cannot clash with an existing variable E.g. for (int i=1; i<10; i++) { … }

36. Export and Import Directives Export: some local scope names are to become visible outside that scope –Typically associated with modularization features such as Ada packages, C++ classes, C compilation units, and Java classes Java: public attribute, String class in java.lang package C: all methods are known outside unless the static attribute is specified In a large software system, the space of global names can become polluted and disorganized –C, C++: Header files –Java: import –Ada: use

37. Altered Search Rules To alter the way in which symbols are found in symbol table –In Pascal: with R do S First try to resolve an identifier as a field of the record R Advantageous if R is a complex name Can usually generate efficient code Forward reference in recursive data structures or methods –A portion of the program will reference a definition that has not yet been processed –Must be announced in some languages

38. Symbol Table Summary The symbol table organization in this chapter efficiently represents scope- declared symbols in a block-structured language Most languages include rules for symbol promotion to a global scope Issues such as inheritance, overloading, and aggregate data types must be considered

39. Declaration Processing Fundamentals Attributes in the symbol table –Internal representations of declarations –Identifiers are used in many different ways in a modern programming language Variables, constants, types, procedures, classes, and fields Every identifier will not have the same set of attributes –We need a data structure to store the variety of information Using a struct that contains a tag, and a union for each possible value of the tag Using object-based approach, Attributes and appropriate subclasses

41. Type Descriptor Structures

42. Type Checking Using an Abstract Syntax Tree Using the visitor pattern (in Chap. 7) –SemanticsVisitor: a subclass of Visitor The top-level visitor for processing declarations and doing semantic checking on the AST nodes –TopDeclVisitor A specialized visitor invoked by SemanticsVisitor for processing declarations –TypeVisitor A specialized visitor used to handle an identifier that represents a type or a syntactic form that defines a type (such as an array)

44. Variable and Type Declarations Simple variable declarations –A type name and a list of identifiers (Fig. 8.12) Visitor actions: (Fig. 8.13)

46. Visit Method

47. Handling Type Names

48. Type Declarations A name and a description of the type to be associated with it –(Fig. 8.15) –Visit method: (Fig. 8.16)

73. Thanks for Your Attention!