Re: EBNF conflict avoidance

Clint Olsen <>
13 Dec 2002 00:14:55 -0500

          From comp.compilers

Related articles
EBNF conflict avoidance (SLK Parsers) (2002-11-20)
Re: EBNF conflict avoidance (Clint Olsen) (2002-11-24)
Re: EBNF conflict avoidance (SLK Parsers) (2002-12-11)
Re: EBNF conflict avoidance (Clint Olsen) (2002-12-13)
Re: EBNF conflict avoidance (SLK Parsers) (2002-12-19)
| List of all articles for this month |

From: Clint Olsen <>
Newsgroups: comp.compilers
Date: 13 Dec 2002 00:14:55 -0500
Organization: AT&T Broadband
References: 02-11-118 02-11-134 02-12-073
Keywords: parse
Posted-Date: 13 Dec 2002 00:14:55 EST

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 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
                      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

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.


Post a followup to this message

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