defines a language with only two sentences - xy and xz. It does so quite unambiguously, but it is not LL(1). An LL(1) equivalent is easily found, of course:

A = 'x' ( 'y' | 'z' ) .

If a grammar is ambiguous it cannot be LL(1). The grammar above for Roman numbers is already non- LL(1) by virtue of the fact that FIRST(OneToThree) and FIRST(FourOrNine) are both the singleton set { "I" } (Rule 1 is broken for the non-terminal Roman.) But it is not this which makes it ambiguous. A string like II could be derived from OneToThree by selecting the first and second Is, or by selecting the first and third Is - it is this which makes it ambiguous. In this case the ambiguity is matched by the failure to meet Rule 2 - in the production

OneToThree = "I" [ "I" ] [ "I" ] .

there are two "nullable" components. For the first of these the FIRST set is { "I" } and "I" is in the FOLLOW set for this component by virtue of its being in the second [ "I" ] component. Probably most ambiguous grammars, if you try to apply the LL(1) rules, will break Rule 2, but I am not sure that this will always be true.

There are numerous ways of correcting the grammar. The brute force one would be to say

Roman = "I" | "II" | "III" | "IV" | "V" | "VI" | "VII" | "VIII" | "IX" | "X" .

and if you suggested that you got credit! Entering more into the spirit of things might lead to productions like

       PRODUCTIONS
         Roman                   = OneToThreeOrFourOrNine | FiveToEight .
         ZeroToTwo               = [ "I" [ "I" ]] .
         OneToThreeOrFourOrNine  = "I" [ ZeroToTwo | "V" | "X"  ] .
         FiveToEight             = "V" [ "I" ZeroToTwo ] .
       END Roman.

This is a "bad" breach of LL(1) - compare this with the dangling else problem, which as we have tried to point out, is actually quite innocuous.

The rest of the changes were far less important - almost an attempt to trick you. Typically folk responded:

(a) "You can only put executable statements, not declarations, into the body of a DoWhile loop.

Well, yes, sort of. You certainly cannot write

          do
            int i;
          while (total < 100);

which you can do in C++ or Java if you like that sort of nonsense. More sensibly, you cannot write

          do
            int i = 6;
            total = total + i;
          while (total < 100);

either, I admit. But you cannot do that in C++ or Java either - where the grammar is defined as

DoWhileStatement = "do" Statement "while" "(" Condition ")" ";" .

which of course fixes the LL(1) problem, while requiring that most DoWhile statements have a Block as the loop body:

          do {
            int i = 6;
            total = total + i;
          } while (total < 100);

(c) "The changes require you to declare variables before you use them".

Alas, no. Both sets are equivalent in that respect, and allow declarations and other statements to be freely mingled (except in the incorrectly specified DoWhile loop!). More generally, productions like

          A = B | C .
          B = "x" | "y" .
          C = "p" | "q" .

and

          A = "x" | "y" | "p" | "q" .
          A = "y" | "p" | "x" | "q" .

or indeed, any other permutations of these, do not force any ordering at all.

(b) "The second set allow you to write meaningless code like

if (a == b) int c;

with only a declaration instead of a statement". Well, yes, but the same apparently useless/meaningless code is allowed by the first set as

if (a == b) { int c; }

Few languages will prevent the dedicated idiots among us from writing meaningless or misleading code, although I suggest C++ is worse in this respect than some other languages I could mention. What do you make of the statements in this gem, which compiles quite happily and illustrates several potentially hard to find bugs?

        void main () {
          int a, b;
          if (a);           while (silly);         while (silly());
          while (a) {}      if (a) 3;              if (a) a+b;
          if (a) int x; else int y;                42;      -6;
          silly;            silly();               a+++--b;
          ++a + + + - - --b;
        }

What I had hoped to get was something on the lines of the following:

        InlineStatement = "pvm" "{" { Code } "}" .
        Code            = OneWord | TwoWord | PrintString .
        OneWord         =   "NOP" | "NEG"  | "ADD"  | "SUB"  | "MUL"  | "DIV" | "REM"
                          | "AND" | "OR"   | "NOT"  | "ANEW" | "LDXA" | "LDV" | "HALT"
                          | "CEQ" | "CNE"  | "CLT"  | "CLE"  | "CGT"  | "CGE" | "STK"
                          | "STO" | "INPI" | "INPB" | "PRNI" | "PRNB" | "PRNL" .
        TwoWord         = ( "LDC" | "LDA"  | "DSP"  | "BRN"  | "BZE" ) [ "+" | "-" ] number .
        PrintString     = "PRNS" stringLit .

As one perceptive person pointed out, the ability to have BRN and BZE statements would be very nice, but the system would be almost totally unusable, since computing the target addresses would be a nightmare. We would need to have some sort of label system, as defined perhaps by

        InlineStatement = "pvm" "{" { Code } "}" .
        Code            = [ Label ] ( OneWord | TwoWord | PrintString ) .
        OneWord         =   "NOP" | "NEG"  | "ADD"  | "SUB"  | "MUL"  | "DIV" | "REM"
                          | "AND" | "OR"   | "NOT"  | "ANEW" | "LDXA" | "LDV" | "HALT"
                          | "CEQ" | "CNE"  | "CLT"  | "CLE"  | "CGT"  | "CGE" | "STK"
                          | "STO" | "INPI" | "INPB" | "PRNI" | "PRNB" | "PRNL" .
        TwoWord         = ( "LDC" | "LDA"  | "DSP"  | "BRN"  | "BZE" )
                          ( Label | [ "+" | "-" ] number ) .
        PrintString     = "PRNS" stringLit .
        Label           = identifier .

introduce a new non terminal RepeatedOptions

RepeatedOptions = { Option } .

and then rewrite the rules for P as

P = Something RepeatedOptions SomethingElse
RepeatedOptions = Option RepeatedOptions | e .

Similarly, and even more simply, if you have something like

Q = Startoff [ OneOption ] Finish

introduce a new non terminal Possible

Possible = [ OneOption ] .

and then rewrite the rules for Q as

Q = Startoff Possible Finish
Possible = OneOption | e .

With that idea, the PRODUCTIONS extract given above might become:

         InlineStatement = "pvm" "{" Codes "}" .
         Codes           = Code Codes | e .
         Code            = OneWord | TwoWord | PrintString .
         OneWord         =   "NOP" | "NEG"  | "ADD"  | "SUB"  | "MUL"  | "DIV" | "REM"
                           | "AND" | "OR"   | "NOT"  | "ANEW" | "LDXA" | "LDV" | "HALT"
                           | "CEQ" | "CNE"  | "CLT"  | "CLE"  | "CGT"  | "CGE" | "STK"
                           | "STO" | "INPI" | "INPB" | "PRNI" | "PRNB" | "PRNL" .
         TwoWord         = ( "LDC" | "LDA"  | "DSP"  | "BRN"  | "BZE" ) Sign  number .
         Sign            = "+" | "-" | e .
         PrintString     = "PRS" stringLit .

Then one has to find a way to extend the token definition for number to be able to express float literals as well as int literals. The problem here is to make sure that all the valid combinations are allowed, unambiguously, insisting that at least one digit appear, and with no possibility of obtaining several periods or Es in one number. For the examples given, the following would suffice

number = digit { digit } [ "." { digit } ] [ "E" [ "+" | "-" ] digit { digit } ] .

Attempts like the following are wrong (you should puzzle out why this is so)

number = digit { digit | "." } "E" { "+" | "-" | digit } .
number = digit { digit | "." | "E" | "+" | "-" } .

Some languages allow you to have float numbers like 123. or 12.E-4 or .456 or .35E+1 -does the above definition allow these? If not, how would you write a token definition to handle all those possibilities as well?

Several submissions tried definitions like

intnumber = digit { digit } .
floatnum = intnumber [ "." intnumber [ "E" [ "-" ] intnumber ] ] .