Class 15: Semantic actions

Held Friday, October 2, 1998

Notes

• Reminder: the due date for both assignment 5 (parser) and assignment 6 (parsing) is now next Wednesday.
• As you can tell, we've begun to deviate from the syllabus. We'll work on staying close to it.
• Hilary, Kevin, Raphen, and Sarah will be presenting posters in the Science Elbow from 10am-noon this Saturday as part of family weekend. Feel free to stop by and see what cool things they did this summer.
• Welcome to any parents visiting today.

Attributes

• As you know, the parse tree is only one step on the way to compilation of a source text.
• What do we do next? Typically, we add attributes to the nodes of the parse tree.
• An attribute is a computed value associated with a node in the parse tree.
• What can attributes be computed from? Typically values of ``neighboring'' nodes (children, parent, siblings).
• How are they computed? Using a rule that is associated with a production in the language.
• Grammars augmented with rules are called attribute grammars.
• What kinds of attributes can be computed? A wide variety. We typically compute
  • symbol tables to use in type checking and correctness analysis;
  • values of expressions (typically in building interpreters);
  • abstract syntax trees that correspond to the structure underlying the parse tree. Such ASTs help eliminate problems of parse trees introduced by changes to the syntax required by parsing techniques;
  • some compilers use attributes to compute code for the parse tree. Appel recommends against this.
• How are the rules applied? In the abstract, one can say that a topological sort of the dependencies is done and the rules are applied in order.
• In practice, a rule is applied when the corresponding production is ``executed'' by the parser.
  • This limits the types of rules that are allowed.
  • In an LR parser, attributes must by synthesized: computed from the attributes of the children.
  • In an LL parser, attributes can also be inherited: computed from attributes of the children or left siblings.
• In practice, rules can also do things other than compute values. This means that the behavior of the parser depends on the order in which the rules are applied. This is a bad thing, and you should not write rules that have such side effects.

An attribute grammar for evaluating expressions

• Let's consider how we might compute a value of arithmetic expressions as they are parsed.
• What attributes will we need?
  • A value attribute (associated with expressions, terms, factors, and numbers) is clearly necessary.
  • In order to compute the values of variables (identifiers), we'll need to look them up in a symbol table. We'll leave that as a subject for future research.
  • We might also want to deal with the type of expressions. Again, we'll leave that as a subject for future research.
• Some rules are fairly trivial, as they only involve copying attributes

  Exp ::= Term
    Exp.value = Term.value
  Term ::= Factor
    Term.value = Factor.value
  Factor ::= OPEN Exp CLOSE
    Factor.value = Exp.value
  

• For the ``base case'' of numbers, we simply get the value of the number (we assume that this is computed during the lexical analysis phase)

  Factor ::= NUMBER
    Factor.value = NUMBER.value
  

• If all that we have for tokens is the ``string representation'', we will need to convert it

  Factor ::= NUMBER
    Factor.value = stringToNumber(NUMBER.string)
  

• Addition and subtraction are also fairly easy

  Exp_0 ::= Exp_1 + Term
    Exp_0.value = Exp_1.value + Term.value
  Exp_0 ::= Exp_1 - Term
    Exp_0.value = Exp_1.value - Term.value
  

• If we use yacc or bison, the rules will look like

  exp ::= exp PLUS exp    { $$ = $1 + $3; }
  exp ::= exp MINUS exp   { $$ = $1 - $3; }
  

• If we use CUP, the rules will look more like

  exp ::= exp:e1 PLUS exp:e2 
       

• If we treat MULTIPLY and DIVIDE as tokens, we might write something like

  MulOp ::= MULTIPLY
    MulOp.fun = f(x,y) { return x * y; }
  MulOp ::= DIVIDE
    MulOp.fun = f(x,y) { return x / y; }
  

• We can then add a rule for terms

  Term_0 ::= Term_1 MulOp Factor
    Term_0.value = MulOp.fun(Term_1.value, Factor.value)
  

An attribute grammar for types

• What if we want to use an attribute grammar (or some related mechanism for computing attributes) to do type checking?
• We need to be able to assign a type to every identifier (not just variables, but also functions).
• A type table can be used to do this association.
  • A more general lookup table can be used for other similar tasks.
  • These tables will be attributes of nodes in the parse tree.
• The typical mechanism for doing this can be awkward for LR parsers. Consider the declaration mechanism for Tiger, which is something like

  exp ::= LET declarations IN exp1 END
  

  • Now, the type assignments available to exp1 should be the type declarations available to exp modified by the additional settings from declarations.
  • We might write this as

      exp1.typeTable = 
        exp.typeTable.extendWith(declarations.typeTable)
    

  • However, in LR grammars it is typically illegal to have such a dependency (since we don't know that we've matched this production until we've hit the end of the production).
  • What should we do? Appel points out that it is certainly reasonable to do a multiple-pass analysis. It is also sometimes more appropriate to do this analysis after building an abstract syntax tree (described next class).
• Another problem arises when we consider function calls. Typically, we need to call at least one function before we define it (e.g., if we have mutually recursive functions).
  • How do we know that the call is legal, since we don't (yet) know the type of the called function?
  • How do we even know that the function exists?
  • C and Java require predeclarations in such cases.
  • Appel again suggests that following multiple steps is more appropriate.

History

• Created Friday, October 2, 1998 (introductory sections taken from the previous outline; section on type checking newly written). See that outline for more information on the sources of the first few sections.
• On Monday, October 5, 1998, I moved a section on parser generators to the subsequent outline. Note also that what we discussed in class did not correspond precisely to this outline.