In the exercises below, "e" will stand for the empty sequence of tokens. Also, since the main theme of these is arithmetic expressions, "E" will stand for a whole expression, instead of using "program". 1a. The grammar E-> E + E E-> E - E E-> num is ambiguous. Show two parse trees for 1 + 2 3 - 4 that turn out to have different answers when you actually do the arithmetic. Rewrite the grammar, possibly introducing new nonterminals, so the language is left associative, that is, 1 + 2 3 - 4 parses as ((1 + 2) - 3) - 4. 1b. The grammar E-> E + E E-> E - E E-> E *E E -> E / E E-> num is ambiguous. Show two parse trees for 1 + 6/3 * 4 that turn out to have different answers when you actually do the arithmetic. Rewrite the grammar, possibly introducing new nonterminals, so that * and / have precedence over + and - (that is, * and / happen before + and - when the arithmetic is actually done), * and / are left-associative among themselves, and + and - are left-associative among themselves, so 1 + 6 / 3 4 parses as 1 + ((6 / 3) * 4). 10. The common if-then-else construct of programming languages is notoriously ambiguous: statement -> if expr then statement else statement statement -> if expr then statement statement ->S where I am letting s stand for any non-if statement, and expr is a Boolean expression you need not worry about further. * Show two different parse trees for if expr then if expr then s else s Rewrite the grammar, possibly introducing new nonterminals, so that an "else" always goes with the immediately preceding available "if", so you would get if expr then { if expr then s else s }