Re: EBNF conflict avoidance

SLK Parsers wrote:
> I can see only one relatively obscure LL(k)/strong LL(k) issue, and only
> for k>1, since LL(1) is also strong. The conflict is avoided because EBNF
> constructs are equivalent to new and unique nonterminals in the grammar.
> See http://parsers.org/parsing.html#8 for more explanation.
>
> The SLK parser-generator now supports the EBNF operators [], {}, and {}+.
> Separate actions for the null and non-null cases can be specified. This
> support provides the conflict avoidance described above.


I was thinking about this and your other post asking about suggestions
to run action code in the event you use EBNF. I didn't entirely
understand the methodology you described, but I believe I understood
the issue you were trying to address.


Since your parser is predictive, it seems actually easier to support
since you generally should pass a pre-initialized objects to be filled
in the rule (a la Coco/R). So, the semantic action should pop for the
list and pop also for the item to append. Then you avoid the annoying
yacc idiom of initializing once but having duplicate append code:


list ::= list item
                  {
                    append($1, $2);
                  }
            | item
                  {
                      init($$);
                      append($$, $1);
                  }
            ;


If there is no item, the result is an initialized but empty list. In your
software you would generally want to do this regardless if the list was
populated.


So, I would actually approach it from the standpoint of providing an
init-block and then and action block in the event the rule is matched.


-Clint

Return to the comp.compilers page.
Search the comp.compilers archives again.