Computing symbol tables

The second step in writing a MOOL compiler should be the generation of the symbol tables associated with the relevant scopes of a MOOL program. Observe from the MOOL grammar, that the relevant scopes are given by the following nonterminals.

• Program
• ClassDeclaration
• MethodBody
• MainBody

Hence one should construct the following tables.

ProgramTable

is the table associated with Program. Each entry consists of a declared class, say Class, and a pointer to the symbol table of Class.

ClassTable

is the table associated with a class, say Class. Each entry consists of a member (attribute or method) of the class. Of course, this table can be split into two tables: one for the attributes and one for the methods. Observe that each method entry consists of

• the method name,
• the formal parameters (with their types),
• a pointer to the table associated with the body of the method, say MethodBodyTable

Each attribute entry consists of

• the attribute name,
• the attribute type.

MethodBodyTable

is the table associated with each method body. Each entry consists of

• an identifier,
• its associated value,
• the type of its associated value.

Moreover since a method is always applied to an implicit object (this) there should be an entry for it.

MainBody

is similar to a table associated with a method body, except that there is no entry for this.

Observe that for simplicity we do not consider local variables in loop bodies. So there is no need of symbol tables for loop bodies.

Even with this, dealing with nested scopes remains not very easy when writing a compiler for the first time. So you may proceed step by step.

First, you could restrict to MOOL programs with

• a unique class declaration and
• an empty MainBody.

Therefore only one ClassTable is needed and then the ProgramTable is not needed any more. We answer now the following questions.

Q1

How do we avoid the construction of MethodBodyTables?

R1

In fact a MethodBodyTable can be viewed as an entry of the ClassTable. This entry should store the information which makes sense only in the scope of the Method, like its formal parameters.

Q2

When parsing the formal parameters of the Method how do we keep track of its entry in ClassTable?

R2

Consider the rule

MethodDeclaration	$\longmapsto$	MethodName ( FormalParamterList ) {
		MethodBody
		}

Remember that a yacc program is a translation scheme: an action can take place bewteen two grammar symbols in the right side of a production. Then, in the yacc program for parsing MOOL, after the nonterminal MethodName one can set up a pointer to the entry of ClassTable corresponding to the current MethodDeclaration.

Second, you can consider a MOOL program with

• a unique class declaration and
• an non empty MainBody.

Then the ProgramTable may consist of an entry for the ClassTable and one entry per variable declared in the MainBody.