Homework #2 Solution Sketches:

1)

Syntax rule: <assign> -> <var> = <expr>

Syntax rule: <expr> -> <var>[2] + <var>[3]
Predicate: <var>[2].actual_type = <var>[3].actual_type

Syntax rule: <expr> -> <var>

Syntax rule: <var> -> A | B | C
Semantic rule: <var>.actual_type = look-up (<var>.string)

(i.e., you will not need any inherited attributes)

2) Consider the following sentence:

   if if stmt1 else stmt2 else stmt3

which is legal in the given grammar. In this sentence, 

   FIRST ([ else <stmt> ]) = else,
   FOLLOW ([ else <stmt> ]) = else,

and therefore 
	FIRST ([ else <stmt> ]) != FOLLOW ([ else <stmt> ]) 
does not hold.

3)

One option is to use an attribute grammar; another is
to write down exhaustively all the possibilities. Here
is one solution.

<stmt> -> declare id <option_list>
<option_list> -> [<mode>] [<scale>] [<precision>] [<base>]
<option_list> -> [<mode>] [<scale>] [<base>] [<precision>]
<option_list> -> [<mode>] [<base>] [<scale>] [<precision>]
   ...
   4!-3 other productions for <option_list>
   ...
<option_list> -> [<base>] [<precision>] [<scale>] [<mode>]
<mode> -> real | complex
<scale> -> fixed | floating
<precision> -> single | double
<base> -> binary | decimal

Now this solution is not so elegant since the grammar is ambiguous
(e.g., there are multiple parses for "declare zippy fixed single").
Still this question only asked us to revise the grammar to avoid
incorrect declarations. It is possible to cleverly restrict
the alternate productions for <option_list> so that ambiguity is
removed.