Issue 1254:  Grammar rule issue (obv-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: The new grammar rule:
         <state_member> ::= <public_token> <type_spec> <declarators> ";"
                     | <type_spec> <declarators> ";"
 seems to open up another large hole for making the grammar non-LALR(1), which may 
 or may not have been intentional. This becomes clear as you work your way back 
 through the set of grammar rules. For example, according to the way I read the rules,
 the following is legal "new" IDL:
 

Resolution: := <public_token> <type_spec> <declarators> ";"
Revised Text: 
Actions taken:
April 28, 1998: received issue
July 30, 1998: closed issue
Discussion: 

End of Annotations:=====
 The new grammar rule:
        <state_member> ::= <public_token> <type_spec> <declarators>
";"
                    | <type_spec> <declarators> ";"
seems to open up another large hole for making the grammar
non-LALR(1), which may 
or may not have been intentional. This becomes clear as you work your
way back 
through the set of grammar rules. For example, according to the way I
read the rules,
the following is legal "new" IDL:
 
module foo {
    value foo2 {
        struct foo3 { ...arbitrarilly long definition... };  
        // The ';' finally tells us its a simple struct dcl 
        // (i.e. part of the <struct_type> -> <type_dcl> -> <export>
-> 
		//                        <value_element> rule)
        struct foo4 { ...arbitrarilly long definition... } x; 
        // The identifier 'x' finally tells us its a state member 
        // (i.e. part of the <struct_type> -> <constr_type_spec> ->
<type_spec> ->
        //                        <state_member> -> <value_element>
rule).
    };
};
 
There are quite a few similar (though different) cases like this. This
is 
particularly messy for us, because our current parser uses recursive
descent,
and the inability to determine which rule to apply based on the next
token 
makes the code extremely messy (prior to OBV, there were no such
problems).
 
My comment on this is that this problem could have been easily averted
by 
changing the <state_member> rule to:
        <state_member> ::= <public_token> <type_spec> <declarators>
";"
                    | <private_token> <type_spec> <declarators> ";"
        <private_token> ::= "private"
This (or similar rule change) would have made the grammar much simpler
to parse.


Return-Path: <vinoski@iona.com>
X-Sender: vinoski@mail.boston.iona.ie
Date: Mon, 15 Jun 1998 16:40:22 -0400
To: obv-rtf@omg.org, issues@omg.org
From: Steve Vinoski <vinoski@iona.com>
Subject: issue 1254

OBV issue 1254 already points out the existing LALR(1) ambiguity
between
value operation declarations and state member declarations, but it
says
that "this could have been easily averted by changing the state member
rule" to require either "public" or "private" in front of the state
member.
In other words, the issue currently tells how to fix the problem, but
it
does not actually propose that the fix be made.

I therefore propose that the grammar be changed to require either
"public"
or "private" on state member declarations in order to make the grammar
LALR(1).

--steve