Re: [SOLVED with questions] Identifying start of new rule

[Chris verBurg]

On Sun, Jun 16, 2013 at 10:17 AM, Test User <address@hidden> wrote:

> A new grammar in combination with %glr-parser worked.
>

Woot!


Question:
>
> (1)I understand that if I have a file of the form:
> <lhs1> ::= <rhs1> <lhs2> ::= <rhs2>, bison parses my rules by default
> as (<lhs1> ::= <rhs1> <lhs2>) ::= <rhs2> and generates a syntax error
> when it reaches the ::= before <rhs2>.  In Bison terminology (I hope),
> after recognising <rhs1>, I want Bison to reduce <lhs1> ::= <rhs1> to
> <rule>, but the next token '<' does not give it a reason to do so. It would
> have to skip '<', 'lhs2', '>' and finally arrive at '::=' to know that
> (<lhs1> ::= <rhs1> <lhs2>) will not work. Therefore, as written, a 2-token
> lookahead as suggested by Ron Burk would not help me. Am I
> understanding correctly?
>
> However, if I defined a token RULE_NAME as, for example
> \< [A-Za-z_]+\>
> then after matching the longest possible sequence of tokens in:
> NAME ::= NAME ...<end-of-rule> NAME ::= <whatever> so that I am at
> <end-of-rule>, where I want to reduce, then a 2-token lookahead *would*
> help in this case. Is that right?
>

>From the comfort of my armchair theorizing, I think you've got the story
right.  After the first <rule_name> it sees, every subsequent <rule_name>
is a shift/reduce conflict, whose default resolution (shift) is what you
want....except for the very last one, but you can't tell it's the last one
until you look that second token ahead to see the "::=".

-Chris