Re: Yacc shift/reduce conflicts

=?ISO-8859-1?Q?Hugues_Cass=E9?= <>
22 Dec 2004 01:05:24 -0500

          From comp.compilers

Related articles
Yacc shift/reduce conflicts (Martyn Weiss) (2004-12-19)
Re: Yacc shift/reduce conflicts (Scott Nicol) (2004-12-22)
Re: Yacc shift/reduce conflicts (=?ISO-8859-1?Q?Hugues_Cass=E9?=) (2004-12-22)
Re: Yacc shift/reduce conflicts (Dawid Pawlata) (2004-12-22)
| List of all articles for this month |

From: =?ISO-8859-1?Q?Hugues_Cass=E9?= <>
Newsgroups: comp.compilers
Date: 22 Dec 2004 01:05:24 -0500
Organization: Guest of ProXad - France
References: 04-12-094
Keywords: yacc
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 */
| someterminal

Martyn Weiss wrote:
> Hi.
> 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.
> S1;S2;...SN
> .
> 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:
> program:
> statements
> ;
> statements:
> statement
> | statements semicolon
> | statements semicolon statement
> ;
> statement:
> someterminal
> ;
> 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.

Post a followup to this message

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