Up: Design

Mimickry Principle

Structural Mimickry: When defining a data structure to store program or architecture information, try to structure the information similar to the structure of the programming language's grammar or architecture. This approach will make the data structure easier to understand and to manipulate.

Execution Mimickry: Likewise, when keeping track of semantic information such as types, pretend that the program parse is an execution of the program, and the semantic information is the data that the program is manipulating. Although the parser is only processing a stream of short strings, the analogy to executing the program provides leverage.

Symbol Table Structure

Note that an Oberon program is a sequence of variable, type, and procedure declarations. Likewise, a formal parameter declaration and local variable declaration are sequences of declarations. The sequence of declarations indicates that symbol information for the body might as well be represented as a list of symbols. In the Oberon language, a declaration may define a (nested) scope (e.g., procedures nest in full Oberon, and records define a scope), it is reasonable to define symbol tables in a nested fashion. In particular, why not have one symbol table (or symbol list) per declared scope? Of course, while parsing the new scope, the new symbol table is the ``current symbol table'' into which all new entries are inserted.

Managing Type Information

When performing type checking of expressions, treat the operations in the program as operations on types (instead of on values). For example, integer + integer = integer, and integer + real = real. This can be expanded into a full table that is not unlike those arithmetic tables from our childhood.

 * Here, we are ``adding'' the types Expr1 and Expr2 and
 * this becomes the value of Expr0
Expr : Expr '+' Expr  { $$ = BinOpCheck($1,$3); ...}

William Griswold
Sun Dec 31 18:26:15 PST 1995