|Yacc shift/reduce conflicts email@example.com (Martyn Weiss) (2004-12-19)|
|Re: Yacc shift/reduce conflicts firstname.lastname@example.org (Scott Nicol) (2004-12-22)|
|Re: Yacc shift/reduce conflicts email@example.com (=?ISO-8859-1?Q?Hugues_Cass=E9?=) (2004-12-22)|
|Re: Yacc shift/reduce conflicts firstname.lastname@example.org (Dawid Pawlata) (2004-12-22)|
|Date:||22 Dec 2004 01:05:24 -0500|
|Organization:||Guest of ProXad - France|
|Posted-Date:||22 Dec 2004 01:05:24 EST|
I think this grammar is at less LALR(1) if you have only one terminal
in someterminal. But it should become LALR(k) if you have at most k
terminals in someterminal.
I think that rules (1) and (3) may create ambiguity according their
derivation. The following form would be better, I guess:
| statements semicolon statement
/* empty */
Martyn Weiss wrote:
> I'm updating a language grammar I wrote a while ago using MKS Yacc,
> which consists of one or more statements separated by semicolons, i.e.
> One of the things I want to do is to allow for superfluous embedded
> and trailing semicolons, as in S1;;S2;
> I had a bit if trouble expressing this in rules without getting
> shift/reduce conflicts. I found that if I simplify the grammar down
> to the following:
> | statements semicolon
> | statements semicolon statement
> yacc reports no conflicts, but it looks a bit clumsy to me. However,
> if I replace "someterminal" by "expression", which has a number of
> alternative definitions (simpleexpression, term, factor, etc) I
> immediately get a whole raft of shift/reduce conflicts, which leads me
> to think the simplified version above isn't the best way to express
> the "superfluous semicolons" point mentioned above.
> Can anyone suggest a better formulation of "statements" or explain how
> I go about getting rid of the s/r conflicts in the fuller version.
Return to the
Search the comp.compilers archives again.