Ambiguity in Grammars A grammar is ambiguous if

An Ambiguous Expression Grammar <assign> -> <id> = <expr> <id> -> A|B|C <expr> -> <expr> + <expr> |<expr> * <expr> |(<expr>) |<id> <assign> a. A=B+C*A b. <assign> <id> = <expr> A <expr> + <expr> <id> <expr> * B <id> C A B C <expr> Copyright © 2006 Addison-Wesley. All rights reserved. <id> = <expr> A <expr> * <expr> + <expr> <id> A 3 -19

Operator Precedence • An operator in an arithmetic expression is generated lower in the parse tree (and therefore must be evaluated first) can be used to indicate that it has precedence over an operator produced higher up in the tree • As in previous slides – Tree a: A = B + (C * A) – Tree b: A = (B + C ) * A Copyright © 2006 Addison-Wesley. All rights reserved. 3 -20

An Unambiguous Expression Grammar <assign> -> <id> = <expr> <id> - > A | B | C <expr> - > <expr> + <term> <id> |<term> - > <term> * <factor> A |<factor> - >(<expr>) |<id> Copyright © 2006 Addison-Wesley. All rights reserved. <assign> = <expr> + <term> * <factor> <id> B C <factor> <id> A 3 -21

Leftmost and leftmost derivations leftmost: <assign> =><id> = <expr> =>A = <expr> Þ A = <expr> + <term> Þ A = <term> + <term> Þ A = <factor> + <term> Þ A = <id> + <term> Þ A = B + <term> * <factor> Þ A = B + <factor> * <factor> Þ A = B + <id> * <factor> Þ A = B + C * <id> ÞA=B+C*A rightmost: <assign> =><id> = <expr> + <term>*<factor> =><id> = <expr> + <term>*<id> =><id> = <expr> + <term>*A =><id> = <expr> + <factor> * A Þ<id> =<expr> + <id> * A Þ<id> = <expr> + C * A Þ<id> = <term> + C * A Þ<id> = <factor> + C * A Þ<id> = <id> + C * A Þ<id> = B + C * A ÞA = B + C * A Every derivation with an unambiguous grammar has a unique parse tree, although that tree can be represented by different derivations. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -22

3. 3. 2 Extended BNF • Optional parts are placed in brackets [ ] <selection> -> if (<expression>) <statement> [else <statement>] • Repetitions (0 or more) are placed inside braces { } <ident_list> -> <identifier> {, <identifier>} • When a single element must be chosen from a group, the options are placed in parentheses and separated by the OR operator, |. <term> -> <term> (* | / | %)<factor> Copyright © 2006 Addison-Wesley. All rights reserved. 3 -23

BNF and EBNF • BNF <expr> + <term> | <expr> - <term> | <term> * <factor> | <term> / <factor> | <factor> • EBNF <expr> <term> {(+ | -) <term>} <term> <factor> {(* | /) <factor>} Copyright © 2006 Addison-Wesley. All rights reserved. 3 -24

EBNF variations • In place of the arrow, a colon is used and the RHS is placed on the next line • Instead of a vertical bar to separate alternative RHSs, they are simply placed on separate lines • In place of squared brackets to indicate something being optional, the subscript opt is used. E. g. – Constructor. Declarator -> Simple. Name(Formal. Parameter. Listopt) • Rather than using the | symbol in a parenthesized list of elements to indicate a choice, the words “one of” are used. E. g. – Assignment. Operator -> one of = *= /= %= += -= <<= >>= &= |= Copyright © 2006 Addison-Wesley. All rights reserved. 3 -25

Attribute Grammars • Extension of Context-free grammars • Context-free grammars cannot describe all of the syntax of programming languages – E. g. “All variables must be declared before they are referenced. ” – This rule cannot be specified in BNF. • Additions to CFGs to carry some semantic info along parse trees, e. g. type checking • Primary value of attribute grammars (AGs) – Static semantics specification – Compiler design (static semantics checking) Copyright © 2006 Addison-Wesley. All rights reserved. 3 -26

Attribute Grammars • Leads to another category of language rules called static semantics rules • Static semantics of a language is only indirectly related to the meaning of programs during execution. • It has to do with the legal forms of programs (syntax rather than semantics) • Many static semantics rules state a language’s type constraints. • Type checking are done at compile time. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -27

Attribute Grammars • Attribute Grammar – a powerful mechanism that describes both syntax and

Attribute Grammars: Basic Concepts • Attributes – Associated with grammar symbols – Similar to variables in the sense that they can have values assigned to them. • Attribute Computation Functions – Also called semantics functions – Associated with grammar rules • Predicate Functions – State the static semantics rules – Associated with grammar rules Copyright © 2006 Addison-Wesley. All rights reserved. 3 -29

Attribute Grammars : Definition • An attribute grammar is a context-free grammar with the following additional features: 1) - Associated with each grammar symbol X is a set of attribute values A(X). - The set A(X) consists of two disjoint sets S(X) and I(X) - S(X): Synthesized attributes, pass semantic information up a parse tree I(X): Inherited attributes, pass semantic information down and across a tree Copyright © 2006 Addison-Wesley. All rights reserved. 3 -30

Attribute Grammars : Definition S(X): synthesized attributes of X { A(X) I(X): inherited attributes of X X 0 X 1 …… Synthesized attributes of X 0 - values depend on child nodes Xn Copyright © 2006 Addison-Wesley. All rights reserved. Inherited attributes of Xn – values depend on parent node or sibling 3 -31

Attribute Grammars : Definition 2) Each rule has a set of functions that define certain attributes of the non-terminals in the rule. For a rule X 0 -> X 1 … Xn: a. The synthesized attributes of X 0 are computed with semantic functions of the form S(X 0) = f(A(X 1), …, A(Xn)). So the value of a synthesized attribute on a parse tree node depends only on the values of the attributes on that node’s children nodes. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -32

Attribute Grammars : Definition X 0 X 1 …… S(X 0) || Xn Copyright

Attribute Grammars : Definition b. The inherited attributes of Xj, 1≤j≤n are computed with semantic functions of the form I(Xj) = f(A(X 0), …, A(Xn)). So the value of an inherited attribute on a parse tree node depends only on the values of the attributes on that node’s parent node and those of its sibling nodes. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -34

Attribute Grammars : Definition X 0 parent X 1 … Xj … Xn I(Xj) = f(A(X 0), …, A(Xn)) sibling X 0 X 1 … Xj-1 Xj … Xn Copyright © 2006 Addison-Wesley. All rights reserved. Often restricted to I(Xj) = f(A(X 0), …, A(Xj-1)) Only depends on attributes of the parent and the left siblings 3 -35

Attribute Grammars : Definition 3) Each rule has a (possibly empty) set of predicates to check for attribute consistency. A predicate function has the form of a Boolean expression on the union of the attribute set {A(X 0), …, A(Xn)} and a set of literal attribute values. The only derivations allowed with an attribute grammar are those in which every predicate associate with every nonterminal is true. A false predicate function value indicates a violation of the syntax or static semantics rules of the language. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -36

Attribute Grammars: Intrinsic Attributes • intrinsic attributes are synthesized attributes of leaf nodes whose values are determined outside the parse tree. E. g. The initial values of variables come from declaration statements. These values can be used to compute the remaining attribute values on a parse tree. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -37

Attribute Grammars: An Example • Syntax rule: <proc_def> ->procedure <proc_name>[1] <proc_body> end <proc_name>[2]; • Predicate: <proc_name>[1]. string == <proc_name>[2]. string Copyright © 2006 Addison-Wesley. All rights reserved. 3 -38

Attribute Grammars: Another Example • Syntax and semantics descriptions: – The only variable names are A, B, and C – The right side of the assignments can either be a variable or an expression in the form of a variable added to another variable. – The variables can be one of two types: int or real – When there are two variables on the right side of an assignment, they need not be the same type. – The type of the expression when the operand types are not the same is always real. When they are the same, the expression type is that of the operands. – The type of the left side of the assignment must match the type of the right side. – The assignment is valid only if the LHS and the value resulting from the evaluating the RHS have the same type. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -39

Attribute Grammars: Another Example • E. g. Are the following statements valid? – int A; int B; A = A + B; - int A; real B; B = A + B; - real A; real D; D = A + D; Copyright © 2006 Addison-Wesley. All rights reserved. 3 -40

Attribute Grammars: Another Example • Syntax <assign> -> <var> = <expr> -> <var> + <var> | <var> A | B | C <assign> <expr> <var> A <var>[2] = Copyright © 2006 Addison-Wesley. All rights reserved. A <var>[3] + B 3 -41

Attribute Grammars: Another Example • Attributes of the non-terminals: – actual_type : A synthesized attribute associated with the non-terminals <var> and <expr>. If <var>, the actual type is the intrinsic. If <expr>, it is determined from the actual types of the child(ren) node(s). – expected_type : An inherited attribute associated with the non-terminal <expr>. It is used to store the type that is expected for the <expr>. It is determined by the type of the variable on the left side of the assignment statement. Copyright © 2006 Addison-Wesley. All rights reserved. 3 -42

Attribute Grammars: Another Example The complete attribute grammar: 1. Syntax rule: <assign> <var> = <expr> Semantic rule: <expr>. expected_type <- <var>. actual_type 2. Syntax rule: <expr> <var>[2] + <var>[3] Semantic rule: <expr>. actual_type <if <var>[2]. actual_type = int) and (<var>[3]. actual_type = int) then int else real end if Predicate: <expr>. actual_type == <expr>. expected_type Copyright © 2006 Addison-Wesley. All rights reserved. 3 -43

Attribute Grammars: Another Example 3. Syntax rule: <expr> <var> Semantic rule: <expr>. actual_type <var>. actual_type Predicate: <expr>. actual_type == <expr>. expected_type 4. Syntax rule: <var> A | B | C Semantic rule: <var>. actual_type look-up(<var>. string) Copyright © 2006 Addison-Wesley. All rights reserved. 3 -44

Attribute Grammars: Another Example <assign> expected_type <expr>actual_type <var> A <var>[2] <var>[3] actual_type = A actual_type + B Flow of Attributes Copyright © 2006 Addison-Wesley. All rights reserved. 3 -45

Attribute Grammars: Another Example • How are attribute values computed? 1. <var>. actual_type <- look-up(A) (rule 4) 2. <expr>. expected_type <- <var>. actual_type (rule 1) 3. <var>[2]. actual_type <- look-up(A) (rule 4) <var>[3]. actual_type <- look-up(B) (rule 4) 4. <expr>. actual_type <- either int or real (rule 2) 5. <expr>. expected_type == <expr>. actual_type is either TRUE or FALSe (rule 2) Copyright © 2006 Addison-Wesley. All rights reserved. 3 -46