1. Describing Syntax and Semantics
Chapter 3
Describing Syntax and Semantics

2. Chapter 3 Topics Introduction The General Problem of Describing Syntax
Formal Methods of Describing Syntax
Attribute Grammars
Describing the Meanings of Programs: Dynamic Semantics – not covered
Copyright © 2006 Addison-Wesley. All rights reserved.

3. Introduction
Syntax: the form or structure of the expressions, statements, and program units
Semantics: the meaning of the expressions, statements, and program units
Syntax and semantics provide the definition of a language
Users of a language definition include:
Other language designers
Implementers (e.g., compiler writers)
Programmers (the users of the language)
c = 5 + 6;
c <- 11
need agreement!
Copyright © 2006 Addison-Wesley. All rights reserved.

4. The General Problem of Describing Syntax: Terminology
A sentence is a string of characters over some alphabet
A language is a set of sentences
A lexeme is the lowest level syntactic unit of a language (e.g., *, sum, begin)
A token is a category of lexemes (e.g., identifier)
sentence === possible statement
language === possible program
Copyright © 2006 Addison-Wesley. All rights reserved.

5. The General Problem of Describing Syntax: Terminology Example
Example: index = 2 * count + 17;
Lexemes
Tokens
index
identifier =
equal_sign 2
int_literal *
mult_op
count +
plus_op 17 ;
semi_colon
Quick: What are lexemes and tokens in: value = (sum + 10) * 2;
Copyright © 2006 Addison-Wesley. All rights reserved.

6. Formal Definition of Languages
Recognizers
A recognition system reads input strings of the language (i.e., sentences) and decides whether the input strings belong to the language
Detailed discussion in Chapter 4
int sum = 0; => yes!
inti = 10; => no!
recognizer
recognizer === syntax analysis of compiler

7. Formal Definition of Languages
Generators
A device that generates sentences of a language
One can determine if the syntax of a particular sentence is correct by comparing it to the structure of the generator
Cuts down on trial-and-error required by recognizer.
What type of application might use a generator?
Copyright © 2006 Addison-Wesley. All rights reserved.

8. Context-Free Grammars
Developed by noted linguist Noam Chomsky* in the mid-1950s
Language generators, originally meant to describe the syntax of natural languages
Your classmate Jane is smart. (can you evaluate?)
3 + 4 = 5 (can you evaluate?)
Rough analogy – grammars are used to determine if statements have valid syntax, not necessarily to evaluate truth
Copyright © 2006 Addison-Wesley. All rights reserved.

9. Noam Chomsky
Philosopher, cognitive scientist, political activist (libertarian socialism), author.
"If we don't believe in freedom of expression for people we despise, we don't believe in it at all.“
"Unlimited economic growth has the marvelous quality of stilling discontent while maintaining privilege, a fact that has not gone unnoticed among liberal economists.“
"The basic idea which runs right through modern history and modern liberalism is that the public has got to be marginalized. The general public are viewed as no more than ignorant and meddlesome outsiders, a bewildered herd."

10. Grammars & Programming
Chomsky hierarchy is a classification of formal languages. Determines what type of automaton it takes to recognize a language based on the form of the language rules.
Define a class of languages called context- free languages
NOTE: forms of tokens of programming languages (e.g., sum) can be described by regular grammars
Copyright © 2006 Addison-Wesley. All rights reserved.

11. Context-Free Grammar Example
<sentence> -> <noun-phrase><verb-phrase>
<noun-phrase>-><proper-noun>
-><determiner><common-noun>
<proper-noun>->John
->Jill
<common-noun>->car
->hamburger
<determiner>->a
->the
<verb-phrase>-><verb><adverb>
-><verb>
<verb>->eats
->drives
<adverb>->slowly
->frequently
Look at it intuitively here,
we’ll get to formal definition
in a minute….
grammar = parts of speech & how to combine, e.g. <determiner><common-noun> NOT
<determiner><proper-noun>
Copyright © 2006 Addison-Wesley. All rights reserved.

12. Context-Free Grammar Derivation Example
<sentence>-><noun-phrase><verb-phrase>
-><proper-noun><verb-phrase>
-><Jill><verb-phrase>
-><Jill><verb><adverb>
-><Jill><eats><adverb>
-><Jill><eats><slowly>
*example from Sudkamp, Languages and Machines: An Introduction to the Theory of Computer Science
Quick: Return to the grammar and create another sentence.
Copyright © 2006 Addison-Wesley. All rights reserved.

13. So what is a context-free grammar?
A formal system to describe a language
Includes a start symbol – what was the start symbol in our example?
Includes a set of rules or productions that state how a symbol may be replaced by other symbols – what could we use to replace <proper-noun>?
Copyright © 2006 Addison-Wesley. All rights reserved.

14. How is it used?
Application of rules continues until either a sentence is created or an error is found in the input
In the example grammar, which of these are valid sentences?
Jill eats the hamburger
the hamburger drives frequently
How do you know? How would you “trace” this to decide?
Copyright © 2006 Addison-Wesley. All rights reserved.

15. Backus-Naur Form (BNF)
Most widely known method for describing programming language syntax
Provides an exact description of the language
Invented by John Backus to describe Algol 58
Updated by Peter Naur for Algol 60
BNF is a metalanguage used to describe another language
Copyright © 2006 Addison-Wesley. All rights reserved.

16. An Example Grammar non-terminal terminal
<program>  begin <stmts> end
<stmts>  <stmt> | <stmt> ; <stmts>
<stmt>  <var> = <expr>
<var>  a | b | c | d
<expr>  <term> + <term> | <term> - <term> | <term>
<term>  <var> | const
In BNF, abstractions are used to represent classes of syntactic structures--they act like syntactic variables (also called nonterminal symbols)
Copyright © 2006 Addison-Wesley. All rights reserved.

17. BNF Fundamentals Terminals: lexemes and tokens
Non-terminals: BNF abstractions, constructed by grouping smaller constructs (terminals + non-terminals)
Each nonterminal has a rule to show how it is constructed.
A rule has a symbol being defined (the left-hand side (LHS)), an arrow, and a right-hand side (RHS)
A nonterminal symbol can have more than one RHS
Lists are described using recursion
Examples of BNF rules:
<ident_list> → identifier | identifier, <ident_list>
<if_stmt> → if <logic_expr> then <stmt>
<stmt>  <single_stmt> | begin <stmt_list> end
Grammar: a finite nonempty set of rules
Copyright © 2006 Addison-Wesley. All rights reserved.

18. Derivation – Try it!
A derivation is a repeated application of rules, starting with the start symbol and ending with a sentence (all terminal symbols)
Our start symbol: <program>
Example sentence: begin a = b + const end
<program>  begin <stmts> end
<stmts>  <stmt> | <stmt> ; <stmts>
<stmt>  <var> = <expr>
<var>  a | b | c | d
<expr>  <term> + <term> | <term> - <term> | <term>
<term>  <var> | const
Copyright © 2006 Addison-Wesley. All rights reserved.

19. Derivation Example TEXTUAL DERIVATION:
<program>
begin <stmts> end
begin <stmt> end
begin <var> = <expr> end
begin a = <expr> end
begin a = <term> + <term> end
begin a = <var> + <term> end
begin a = b + <term> end
begin a = b + const end
GRAMMAR: <program>  begin <stmts> end <stmts>  <stmt> | <stmt> ; <stmts> <stmt>  <var> = <expr> <var>  a | b | c | d <expr>  <term> + <term> | <term> - <term> | <term> <term>  <var> | const
Copyright © 2006 Addison-Wesley. All rights reserved.

20. Derivation
Every string of symbols in the derivation is a sentential form (e.g., begin <stmt> end)
A sentence is a sentential form that has only terminal symbols (e.g., begin a = b + const end)
A leftmost derivation is one in which the leftmost nonterminal in each sentential form is the one that is expanded
A derivation may be neither leftmost nor rightmost
Most languages are infinite (even though grammar is finite)
We’ll only focus on leftmost, distinction between rightmost/leftmost not that important for our purposes.
Copyright © 2006 Addison-Wesley. All rights reserved.

21. Quick Ex – do leftmost/arbitrary
<program>  begin <stmts> end
<stmts>  <stmt> | <stmt> ; <stmts>
<stmt>  <var> = <expr>
<var>  a | b | c | d
<expr>  <term> + <term> | <term> - <term> | <term>
<term>  <var> | const
Try:
begin a = b; d = c end
What about:
begin a = b + c – d end
Copyright © 2006 Addison-Wesley. All rights reserved.

22. Derivation Example - Leftmost
DERIVATION of begin a=b; d=c end
<program>
begin <stmts> end
begin <stmt>;<stmts> end
begin <var>=<expr>;<stmts> end
begin a=<expr>;<stmts> end
begin a=<term>;<stmts> end
begin a=<var>;<stmts> end
begin a=b;<stmts> end
begin a=b;<stmt> end
begin a=b;<var>=<expr> end
begin a=b;d=<expr> end
begin a=b;d=<term> end
begin a=b;d=<var> end
begin a=b;d=c end
GRAMMAR: <program>  begin <stmts> end <stmts>  <stmt> | <stmt> ; <stmts> <stmt>  <var> = <expr> <var>  a | b | c | d <expr>  <term> + <term> | <term> - <term> | <term> <term>  <var> | const

23. Derivation Example - Arbitrary
DERIVATION of begin a=b; d=c end
<program>
begin <stmts> end
begin <stmt>;<stmts> end
begin <stmt>; <stmt> end
begin <stmt>; <var>=<expr> end
begin <var>=<expr>;<var>=<expr>end
begin <var>=<term>;<var>=<expr>end
begin <var>=b;<var>=<expr> end
begin a=b;<var>=<expr> end
begin a=b; d=<expr> end
begin a=b; d=<var> end
begin a=b; d=c end
GRAMMAR: <program>  begin <stmts> end <stmts>  <stmt> | <stmt> ; <stmts> <stmt>  <var> = <expr> <var>  a | b | c | d <expr>  <term> + <term> | <term> - <term> | <term> <term>  <var> | const

24. Parse Tree A hierarchical representation of a derivation
<program>
<program> => begin <stmts> end
=> begin <stmt> end
=> begin <var> = <expr> end
=> begin a = <expr> end
=> begin a = <term> + <term> end
=> begin a = <var> + <term> end
=> begin a = b + <term> end
=> begin a = b + const end
begin
<stmts>
end
<stmt>
<var> =
<expr> a
<term> +
<term>
<var>
const b
Copyright © 2006 Addison-Wesley. All rights reserved.

25. Correspondence to Code – Quick Exercise
begin
a = b + const
end
c = a + b;
d = b - const
c = a * b;
d = b + const;
<program>  begin <stmts> end
<stmts>  <stmt> |
<stmt> ; <stmts>
<stmt>  <var> = <expr>
<var>  a | b | c | d
<expr>  <term> + <term>
| <term> - <term>
| <term>
<term>  <var> | const
Which ones match the grammar?
Copyright © 2006 Addison-Wesley. All rights reserved.

26. BNF Exercise
Add rules to the example expression grammar to create a BNF for the following constructs:
while loop
for loop
Use the BNF to create a derivation and parse tree for:
begin
a = const;
while (a > const)
b = b + a;
a = a – const;
end
NOTE: depending on how you defined your while, you may need to add { } or begin/end to this code, remove ; etc.
Copyright © 2006 Addison-Wesley. All rights reserved.

27. Review – where are we? Context-Free Grammars BNF Why do we care?
describes a language by specifying how a sentence (consisting of characters from some alphabet) can be derived from a set of rules or productions
rules consist of terminals and non-terminals, and a specific start symbol
BNF
formal notation for representing context-free grammars
Why do we care?
we can use context-free grammars to describe many (but not all!) constructs of programming languages
Copyright © 2006 Addison-Wesley. All rights reserved.

28. Homework Review Solutions??
Copyright © 2006 Addison-Wesley. All rights reserved.

29. Derivation Review – Formal Theory
non-terminals
alphabet
start symbol
grammer
productions
G ({S,A,X,Y}, {a, x, y}, S, p)
p = {S->AXY, A->aA|A, X->x, Y->y}
S=>AXY=>aAXY=> aaXY => aaxY => aaxy
S=>AXY=>AXy => Axy => aAxy => aaxy
Different sentential forms
For context-free grammar, same terminal sentence generated, order doesn’t affect validity (but will affect algorithms…)
Copyright © 2006 Addison-Wesley. All rights reserved.

30. Issues we’ll explore Ambiguity Precedence Associativity
Copyright © 2006 Addison-Wesley. All rights reserved.

31. Issue 1: Ambiguity in Grammars
A grammar is ambiguous if and only if it generates two or more distinct parse trees of same derivation (e.g., leftmost) for same sentence
Compiler chooses code to generate based on parse tree, if ambiguous may not be able to parse correctly.
Characteristics of grammar to determine if ambiguous:
generates sentence with > 1 leftmost derivation OR
generates sentence with > 1 rightmost derivation
NOT just two different parse trees!
What constructs do you think might lead to ambiguity?
Copyright © 2006 Addison-Wesley. All rights reserved.

32. Two Grammars for Assignment
<assign>-><id>=<expr>
<id> -> A|B|C
<expr> -> <id> + <expr>
| <id> * <expr>
| ( <expr> )
| <id>
<assign>-><id>=<expr>
<id> -> A|B|C
<expr> -> <expr> + <expr>
| <expr> * <expr>
| ( <expr> )
| <id>
Allows growth on both left and right.
QUICK EX: Do leftmost derivation of A * B + C for each grammar
Copyright © 2006 Addison-Wesley. All rights reserved.

33. An Unambiguous Grammar
A * B + C
<expr>
<id> -> A|B|C
<expr> -> <id> + <expr>
| <id> * <expr>
| ( <expr> )
| <id>
<id>
<op>
<op>
<expr> A *
<id>
<op>
<expr> B + C
Copyright © 2006 Addison-Wesley. All rights reserved.

34. An Ambiguous Expression Grammar
A * B + C
<id> -> A|B|C
<expr> -> <expr> + <expr>
| <expr> * <expr>
| ( <expr> )
| <id>
<expr>
<expr>
<expr>
<op>
<expr>
<expr>
<op>
<op>
<expr>
<expr>
<op>
<expr> + C A *
<expr>
<op>
<expr> A * B B + C
NOTE: these are two leftmost derivations
Copyright © 2006 Addison-Wesley. All rights reserved.

35. Issue 2: Operator Precedence
A * B + C
Must ensure that operators with higher precedence are performed first
Higher precedence operations should be lower in the parse tree*
Unambiguous grammar does not yield correct precedence. Rightmost operator will be lowest in the parse tree
<expr>
<id>
<op>
<op>
<expr> A *
<id>
<op>
<expr> B + C
* why? would it be possible to evaluate A * <expr> before B + C?
Copyright © 2006 Addison-Wesley. All rights reserved.

36. Grammar with Precedence
How to fix??
Create separate non-terminal operands with different precedence (e.g., <expr>and <term>)
<assign>-><id>=<expr>
<id> -> A|B|C
<expr> -> <expr> + <term>
| <term>
<term> -> <term> * factor>
| <factor>
<factor> -> ( <expr> )
| <id>
Notice lower precedence <expr> listed in earlier rule…
So it can’t be evaluated until <term> is evaluated….
<term> must be lower on parse tree.
Copyright © 2006 Addison-Wesley. All rights reserved.

37. Precedence Quick Exercise
Draw parse tree for:
A * B + C
<assign> -> <id>=<expr>
<id> -> A | B | C
<expr> -> <expr> + <term> | <term>
<term> -> <term> * <factor> | <factor>
<factor> -> ( <expr> ) | <id>
Copyright © 2006 Addison-Wesley. All rights reserved.

38. Operator Precedence Derivation
A * B + C
<expr>
<expr> + <term>
<term> + <term>
<term> * <factor> + <term>
<factor> * <factor> + <term>
<id> * <factor> + <term>
A * <factor> + <term>
A * <id> + <term>
A * B + <term>
A * B + <factor>
A * B + <id>
<assign> -> <id>=<expr>
<id> -> A|B|C
<expr> -> <expr> + <term>
| <term>
<term> -> <term> * <factor>
| <factor>
<factor> -> ( <expr> )
| <id>
Copyright © 2006 Addison-Wesley. All rights reserved.

39. Operator Precedence Parse Tree
A * B + C
<expr>
<expr> + <term>
<term> + <term>
<term> * <factor> + <term>
<factor> * <factor> + <term>
<id> * <factor> + <term>
A * <factor> + <term>
A * <id> + <term>
A * B + <term>
A * B + <factor>
A * B + <id>
<expr>
<expr> + +
<term>
<term>
<factor>
<term> *
<factor>
<id>
<factor>
<id> C
<id> B A
Copyright © 2006 Addison-Wesley. All rights reserved.

40. Issue 3: Associativity of Operators
When two operators have the same precedence, the associativity determines the order of evaluation:
A / B * C could be (A/B) * C or A / (B * C)
Addition is typically associative, meaning left and right associative orders have same value. Not necessarily true if floating point.
Subtraction and division are not associative.
Associativity is not the same as ambiguity!
Copyright © 2006 Addison-Wesley. All rights reserved.

41. Associativity of Operators
A + B + C showing associativity
<assign> -> <id>=<expr>
<id> -> A|B|C
<expr> -> <expr> + <term>
| <term>
<term> -> <term> * <factor>
| <factor>
<factor> -> ( <expr> )
| <id>
<expr>
<expr> + +
<term>
<factor>
<expr> +
<term>
<id>
<term>
<factor>
<factor> C
<id>
<id> B
Notice A added to B, then sum added to C
Why? – because <expr> is leftmost in rule A
Copyright © 2006 Addison-Wesley. All rights reserved.

42. Associativity of Operators
When a grammar has its LHS appearing at beginning of RHS, it is left recursive. Specifies left associativity.
Left recursion disallows some important syntax analysis algorithms. Grammars must be modified to remove left recursion. Compilers must then enforce associativity, even though not dictated by grammar.
Right associativity is specified by right recursion.
We’ll do an exercise in Chapter 4
to remove left recursion
Copyright © 2006 Addison-Wesley. All rights reserved.

43. Associativity of Operators
Right operator associativity can also be indicated by a grammar
<factor> -> <exp> ** <factor>
| <exp>
<exp> -> ( <expr> )
| <id>
LHS appears on right, so
right associative
Copyright © 2006 Addison-Wesley. All rights reserved.

44. Extended BNF
Extensions to BNF enhance readability, not its descriptive power
Optional parts are placed in brackets [ ]
<proc_call> -> ident [(<expr_list>)]
Alternative parts of RHSs are placed inside parentheses and separated via vertical bars
<term> → <term> (+|-) const
Repetitions (0 or more) are placed inside braces { }
<ident> → letter {letter|digit}
What languages does this match/not match?
Copyright © 2006 Addison-Wesley. All rights reserved.

45. BNF vs EBNF Example BNF <expr>  <expr> + <term>
<term>  <term> * <factor>
| <term> / <factor>
| <factor>
EBNF
<expr>  <term> {(+ | -) <term>}
<term>  <factor> {(* | /) <factor>}
Which form do you prefer? Writing vs reading?
Copyright © 2006 Addison-Wesley. All rights reserved.

46. Extended BNF Improves readability and writability of BNF
Helpful link for EBNF:
Copyright © 2006 Addison-Wesley. All rights reserved.

47. Ambiguity Exercise Consider the following If-Else Grammar
<stmt> => if <expr> then <stmt>
| if <expr> then <stmt> else <stmt>
| … (assume other types of stmts are possible)
Show that this grammar is ambiguous. Hint: try
if Expr1 then if Expr2 then Stmt1 else Stmt2
Rewrite the grammar to remove the ambiguity. Hint: Add non-terminals to distinguish two cases (with and without else)
Copyright © 2006 Addison-Wesley. All rights reserved.

48. Ambiguity Review S->S+S | 1 | a Generate 1 + 1 + a
Copyright © 2006 Addison-Wesley. All rights reserved.

49. Attribute Grammars
Context-free grammars (CFGs) and BNF cannot easily describe all of the structure of programming languages
type compatibility (e.g., float = int OK, int = float not OK) would require too many rules
declaring all variables before they are referenced can’t be specified in BNF
Static semantics
legal form of entire program
static because checked at compile time
Copyright © 2006 Addison-Wesley. All rights reserved.

50. Attribute Grammars
Knuth designed Attribute Grammars to describe both syntax & static semantics
Basic concepts used at least informally in every compiler*
AG = CFGs plus:
attributes (values assigned to grammar symbols)
attribute computation functions (how to compute attribute values)
predicate functions (static semantic rules)
* ad hoc methods more often used in compiler implementation, but AG used in other applications, such as natural-language processing
Copyright © 2006 Addison-Wesley. All rights reserved.

51. Attribute Grammars : Definition
An attribute grammar is a context-free grammar G = (Vt, Vn, P, S) with the following additions:
For each grammar symbol x there is a set A(x) of attribute values
Each grammar rule has a set of semantic functions that define certain attributes of the nonterminals in the rule
Each rule has a (possibly empty) set of predicates to check for attribute consistency
A(x) consists of two disjoint sets, synthesized attributes S(x) and inherited attributes (x)
Copyright © 2006 Addison-Wesley. All rights reserved.

52. Attribute Grammars: Attributes
Synthesized attributes: pass semantic information up a parse tree (e.g., calculated at a child node and passed to parent)
Inherited attributes: pass semantic information down and across tree (e.g., passed from parent to child)
Intrinsic attributes: synthesized attributes of leaf nodes whose values are determined outside the parse tree (e.g., type info stored in a symbol table)
Copyright © 2006 Addison-Wesley. All rights reserved.

53. Attribute Grammars: An Example
Idea: define an attribute grammar that can enforce the type rules of an assignment statement
Syntax
<assign> -> <var> = <expr>
<expr> -> <var> + <var> | <var>
<var> -> A | B | C
Attributes
actual_type: synthesized for lhs <var> and <expr>
expected_type: inherited for <expr>
Goal: ensure actual_type is compatible with expected_type
Type Requirements
Variables can be either int or real. Mixed expression type is always real. If operands are the same, result type matches types of operands.
(based on child)
(from parent – think about declaration)
Copyright © 2006 Addison-Wesley. All rights reserved.

54. Attribute Grammar (Example cont)
Syntax rule: <assign>  <var> = <expr>
Semantic rules:
<expr>.expected_type  <var>.actual_type
Syntax rule: <expr>  <var>[2] + <var>[3]
<expr>.actual_type  <var>.actual_type
if (<var>[2].actual_type = int) and
(<var>[3].actual_type = int)
then int
else real
Predicate:
<expr>.expected_type == <expr>.actual_type
Copyright © 2006 Addison-Wesley. All rights reserved.

55. Attribute Grammar (Example cont)
Syntax rule: <expr>  <var>
Semantic rules:
<expr>.actual_type  <var>.actual_type
Predicate:
<expr>.expected_type == <expr>.actual_type
Syntax rule: <var>  A|B|C
<var>.actual_type  look-up(<var>.string)
(intrinsic)
Copyright © 2006 Addison-Wesley. All rights reserved.

56. Example Parse Tree A = A + B <assign> <var> <expr>
Copyright © 2006 Addison-Wesley. All rights reserved.

57. Attribute Grammars (continued)
How are attribute values computed?
If all attributes were inherited, the tree could be decorated in top-down order.
If all attributes were synthesized, the tree could be decorated in bottom-up order.
In many cases, both kinds of attributes are used, and it is some combination of top-down and bottom-up that must be used.
Copyright © 2006 Addison-Wesley. All rights reserved.

58. Decorated Parse Tree lookup <assign> <var> <expr> A
A = A + B
Order:
Rule 4 (lookup A)
<var>.actual_type  look- up(<var>.string)
<assign>
<var>
<expr> A
<var>[2]
<var>[3] =
actual type A + B
lookup
Copyright © 2006 Addison-Wesley. All rights reserved.

59. Decorated Parse Tree lookup <assign> <var> <expr> A
A = A + B
Order:
Rule 4 (lookup A)
<var>.actual_type  look- up(<var>.string)
Rule 1 (var=expr)
<expr>.expected_type  <var>.actual_type
<assign>
<var>
expected type
<expr>
actual type A
<var>[2]
<var>[3] =
actual type A + B
lookup
Copyright © 2006 Addison-Wesley. All rights reserved.

60. Decorated Parse Tree lookup <assign> <var> <expr> A
A = A + B
Order:
Rule 4 (lookup A)
<var>.actual_type  look- up(<var>.string)
Rule 1 (var=expr)
<expr>.expected_type  <var>.actual_type
Rule 4 (lookup A, B)
<assign>
<var>
expected type
<expr>
actual type A
<var>[2]
<var>[3] =
actual type
actual type A + B
lookup
actual type
Copyright © 2006 Addison-Wesley. All rights reserved.

61. Decorated Parse Tree lookup <assign> <var> <expr> A
A = A + B
Order:
Rule 4 (lookup A)
<var>.actual_type  look- up(<var>.string)
Rule 1 (var=expr)
<expr>.expected_type  <var>.actual_type
Rule 4 (lookup A, B)
Rule 2 (expr = var + var)
if (<var>[2].actual_type = int) …
<assign>
<var>
expected type
<expr>
actual type
actual type A
<var>[2]
<var>[3] =
actual type
actual type A + B
lookup
actual type
Copyright © 2006 Addison-Wesley. All rights reserved.

62. Decorated Parse Tree lookup <assign> <var> <expr> A
A = A + B
Order:
Rule 4 (lookup A)
<var>.actual_type  look- up(<var>.string)
Rule 1 (var=expr)
<expr>.expected_type  <var>.actual_type
Rule 4 (lookup A, B)
Rule 2 (expr = var + var)
if (<var>[2].actual_type = int) …
Rule 2 (predicate)
<assign>
expected type = actual_type
<var>
expected type
<expr>
actual type
actual type A
<var>[2]
<var>[3] =
actual type
actual type A + B
lookup
actual type
Copyright © 2006 Addison-Wesley. All rights reserved.

63. Evaluation Checking static semantics is essential part of compilers
Large number of attributes and rules make attribute grammars difficult to read and write
Attribute values on large parse tree are costly to evaluate
This is one area where formalism is good to understand, but ad-hoc methods (e.g., symbol table) have prevailed
Copyright © 2006 Addison-Wesley. All rights reserved.

64. Summary BNF and context-free grammars are equivalent meta-languages
Well-suited for describing the syntax of programming languages
An attribute grammar is a descriptive formalism that can describe both the syntax and the semantics of a language
Copyright © 2006 Addison-Wesley. All rights reserved.