is interpreted only ase(respectively_{1}op e_{2}op' e_{3}e)_{1}op' e_{2}op e_{3 }

In other words,(e(respectively_{1}op e_{2}) op' e_{3}e)_{1}op' (e_{2}op e_{3})

From the point of view of derivation trees, the fact that
**e _{1} op e_{2} op' e_{3}**
is interpreted as

We can eliminate the ambiguities from the grammar in the example of
the arithmetic expressions by introducing a new syntactic category
**Term**
producing expressions of the form

wheree_{1}* e_{2}

Exp ::= Exp + Exp | Term

Term ::= Term * Term | Num

This modification corresponds to assigning *****
a higher priority wrt **+** (following
the mathematical convention). Consider again the string **2
+ 3 * 5**. It is easy to see that in the new grammar there
is only one tree which can generate it:

Exp /|\ / | \ / | \ Exp + Exp | | Term Term | /|\ | / | \ | / | \ Num Term * Term | | | 2 Num Num | | 3 5

In the particular case of the **+** and the
***** operators,
this kind of ambiguity does not cause problems semantically,
because they are both associative, i.e.
**(2 + 3)
+ 5** and
**2 + (3
+ 5)** have the same value. Analogously for
*****.
In general, however, an operator might be not associative. This
is for instance the case for the **-**
and **^** (exponentiation) operators:
**(5 - 3) - 2 **
and
**5 - (3
- 2)**
have different values,
as well as **(5
^ 3) ^ 2**
and
**5 ^ (3
^ 2)**.

In order to eliminate this kind of ambiguity, we mush establish whether
the operator is left-associative or
right-associative.
Left-associative means that **e _{1} op e_{2}
op e_{3}** is interpreted as

We can impose left-associativity (resp. right-associativity) by
using a left-recursive (resp. right-recursive) production for **op**.
For instance, in the example of arithmetic expressions,
we can enforce left-associativity of
**+** and
***** in the following way

This grammar is now unambiguous.Exp ::= Exp + Term | Term

Term ::= Term * Num | Num

Consider the following grammar (productions) for numerical expressions
constructed with the **-** operation:

Exp ::= Num | Exp - Exp

This grammar is ambiguous since it allows both the interpretations
**(5 - 3)
- 2**
and
**5 - (3
- 2)**.
If we want to impose the
left-associativity (following the mathematical convention), it is sufficient
to modify the productions in the following way:

Exp ::= Num | Exp - Num

Consider the following grammar (productions) for numerical expressions
constructed with the **^** operation:

Exp ::= Num | Exp ^ Exp

This grammar is ambiguous since it allows both the interpretations
**(5 ^ 3)
^ 2 **
and
**5 ^ (3
^ 2)**.
If we want to impose the
right-associativity (following the mathematical convention), it is sufficient
to modify the productions in the following way:

Exp ::= Num | Num ^ Exp

StmThis grammar is ambiguous, in fact, the statement::= ifExpthenStm| ifExpthenStmelseStm|... (other stms)

can be interpreted both asifx > 0then ifx = 1then print(1) else print(2)

and asifx > 0then( ifx = 1then print(1) else print(2))

This ambiguity is clearly relevant for the semantics: if the value of x is 2 for example, in the first case the machine should print 2, in the second case should do nothing.ifx > 0then( ifx = 1then print(1)) else print(2)

This ambiguity originates whenever a statement contains an unbalanced
number of **then** and
**else**
(i.e. more **then**
than **else**).
In order to eliminate it, we must establish a rule which determines, for
each **else**,
its matching **then**.
Usually the convention is the following:

EachIn order to impose this rule, one possibility is to modify the productions in the following way:elsematches the last (from left-to-right) unmatchedthen

StmIn this new grammar, the statement above can only have the first kind of structure.::=Bal_Stm|Unbal_Stm

Bal_Stm::= ifExpthenBal_StmelseBal_Stm|... (other stms)

Unbal_Stm::= ifExpthenStm| ifExpthenBal_StmelseUnbal_Stm