Unnamed Web page

Concrete Parse Trees

Tree representation of a derivation - Shows structure!
- Leaves: terminals
- Interior nodes: nonterminals
- Children: substitutions

Example: Expression Grammar: (CAPITALS = nonterminals; lowercase = terminals)

E -> E + E | E * E | (E) | I

I -> a | b | c

E => E + E
  => I + E
  => a + E
  => a + E * E
  => a + I * E
  => a + b * E
  => a + b * I
  => a + b * c

Abstract Parse Tree

Compilers use abstract parse trees rather than concrete parse trees
An abstract parse tree simplifies the concrete tree
- Removes nonterminals
- Puts operators into interior nodes
- Leaves terminals on leaves
Does not show derivation steps

Ambiguous Grammars

In some grammars certain strings can be derived in more than one way. Such grammars are called ambiguous
Def: A grammar is ambiguous iff it can produce one (or more) strings by 2 different leftmost derivations.
Note: A string that can be produced
- by 2 different leftmost derivations can also be produced
- by 2 different rightmost derivations, and is represented
- by 2 different parse trees.

Ambiguous Grammars - Example

Consider this expression grammar:
```
E --> E + E 
    |  a 
```
This string, a + a + a, has 2 leftmost derivations. Thus the grammar is ambiguous.
Remember: The string also has 2 rightmost derivations and 2 parse trees
Although other strings, for example, a + a + a + a, also have 2 derivations, only one is needed to show that the grammar is ambiguous.
Some strings generated by this grammar, for example a+a, have only one derivation. The grammar is still ambiguous.
The grammar is ambiguous NOT because the leftmost and rightmost derivations are different; it is ambiguous because there are 2 different leftmost derivations.

Ambiguous Grammars: Problems and Solutions

Language designers try to avoid ambiguous grammars. They want the grammar to specify whether the expression 2+3*4 should be evaluated as (2+3)*4 or as 2+(3*4).
Remember: Grammars are used to build recognizers and compilers and using an ambiguous grammar to create a compiler would make the compiler more complicated.
Solution: Design a new grammar that generates the same language and that is unambiguous and that gives the desired interpretation.
Source of ambiguity: A LM derivation that begins with E => E+E can next replace the left E with either a (and continue growing from the right E), or with E+E and thus grow on the left.
Solution: Make the grammar either left or right recursive, but not both (here we choose left recursive):
```
E -> E + a
E -> a 
```

More Ambiguity

Now, what about an ambiguous expression grammar that has multiple operators:
```
E -> E + E
E -> E * E
E -> a 
```
Here, the choice occurs at the first step. Either recursive rule will work since the resulting string (either E+E or E*E) can be grown from either side so it is possible start with either production and generate any sequence of plus and times operators.
To solve this problem we again make the grammar either right or left recursive (here we choose right recursive):
```
E -> a + E
E -> a * E
E -> a 
```
In this grammar, since it is only possible to grow on the right, the string must be generated from left to right and the next choice is always determined.
Is this grammar ambiguous?
```
E -> a + E
E -> E * a
E -> a 
```
Note: There is no general algorithm that can take any grammar and figure out whether that grammar is ambiguous.

Ambiguous If Statement

C, C++, Java (but not Ada) all allow

   if (b1) 
      if (b2) 
         s1; 
      else 
         s2;

The following grammar will generate the if statement above (with keyword then added for clarity)

STMT   -> ASSIGN | IFSTMT
ASSIGN -> ...

IFSTMT -> if BOOL then STMT
        | if BOOL then STMT else STMT

The grammar above is ambiguous because there are two leftmost derivations of if then if then s1 else s2 (ie the grammar does not uniquely specify which if the else goes with). The choice occurs at the first step, in which IFSTMT can be expanded using either production.

The following grammar generates the same statements and is unambigous. It matches an else with the closest if that is unmatched or that is not in an begin/end block

STMT -> MATCHED | UNMATCHED

MATCHED   -> if BOOL then MATCHED else MATCHED
           | ASSIGN 
           | begin STMT end 

UNMATCHED -> if BOOL then STMT
           | if BOOL then MATCHED else UNMATCHED

Note that in a MATCHED statement an if either has an else or it is within a begin/end block. (An inductive proof is needed to show this is true since the definition of MATCHED is recursive.)
Also note that the only thing that precedes an else is a matched statement.
Thus it is impossible to have an if-then (without an else) that immediately precedes an else (unless that if-then is within a begin/end block).
Thus, the statment if then if then s1 else s2 can only be generated by starting with the first UNMATCHED production (ie you cannot start by generating the if then else).
Ada avoids the problem by using end if

Associativity

As already seen, grammars can specify associativity
Left Associativity, eg evaluate a+b+c as (a+b) + c
Right Associativity, eg evaluate a+b+c as a + (b+c)
Left Associativity: In parse tree, a+b is lower
Right Associativity: In parse tree, b+c is lower
Note: we evaluate parse trees from the bottom up
Left recursive grammar cause Left Associativity
```
E -> E + T | E
T -> a | b | c
```
Right recursive grammar cause Right Associativity
```
E -> T + E | E
T -> a | b | c
```
Left recursive grammar builds subtrees to the left
Right recursive grammar builds subtrees to the right

Precedence

Grammars can also specify precendence
Want * higher precedence than +
Example: Evaluate a+b*c as a + (b*c)
Parse tree: In this example, we want * below + so that * is evaluated first.

Grammar that specifies * higher than +

E -> E + T | T
T -> T * F | F
F -> a | b | c

In a given expression, we generate all +'s before all *'s (assuming no parentheses) which puts the +'s higher in the parse tree which causes them to be evaluated after the *'s
This expression grammar is unambiguous

Parentheses

We can expand the expression grammar to include other operators and parentheses:
```
E -> E + T | E - T | T
T -> T * F | T / F | F
F -> a | b | c
F -> (E)
```
Operators + and - are left associative and at the same level of precedence. Similarly for * and /.
Expressions within parentheses are found lower in the tree than the other operands of the operators that they are operands of (huh?), and thus the parenthesized expressions are done first.

EBNF - Extended BNF

Provides a shorthand for BNF (but no additional power):
- [] means optional
- (|) means alternates
- { } means 0 or more repetitions

BNF:

E -> E + T | E - T | T

T -> T * F | T / F | F

F -> a | b | c

EBNF:

E -> T { (+ | -) T } 

T -> F { (* | /) F }

F -> a | b | c

We usually assume that operators specified using { and } are left associative, and thus we can use {} to remove left recursion (Later we will see that left recursion complicates some parsing.) .

EBNF - Right Associativity

As a shorthand for right recursive rules (and thus for right associative operators), use []
Example: Add to the expression grammar a right associative exponent operator (ie **). For example 2**3**2 = 2**9 not 8**2.

BNF:

EXPR -> POWR ** EXPR  

      | POWR 

POWR -> POWR + TERM

      | TERM
  ...

EBNF:

EXPR -> POWR [** EXPR]  

POWR -> TERM {+  TERM}
  ...

Actually, the exponent is usually given a high precedence rather the low precedence show here
EBNF is commonly used when building Recursive Descent Compilers

Context Free Grammars

Grammars specified with BNF (or EBNF) are called Context Free Grammars (CFG).
In a CFG, the LHS of a production has only a single nonterminal
Thus CFG productions can't look like
T * -> id *
These productions are context sensitive (CPSC 420)

CFG are limited

Context free grammars can not express several common programming language rules.

Example:

x: Integer;
y: Boolean;
...
y := x;
y := 3;

Type rules can be checked with Attribute Grammars in which symbols have attributes attached to them. An example attribute is the declared type of a variable.
The attributes are passed across rules, in either direction, causing information to be passed up and down the parse tree.

[LaTeX -> HTML by ltoh]

Edward G. Okie
Last modified: Sep 20 2002