Re: LALR(1)- but not LR(1)-conflict

adam@index.ping.dk (Adam Dickmeiss)
Thu, 2 Feb 1995 12:51:00 GMT

          From comp.compilers
Related articles
LALR(1)- but not LR(1)-conflict holzmuel@kafka.informatik.uni-stuttgart.de (1995-01-31)
Re: LALR(1)- but not LR(1)-conflict adam@index.ping.dk (1995-02-02)
Re: LALR(1)- but not LR(1)-conflict salomon@silver.cs.umanitoba.ca (1995-02-03)
Re: LALR(1)- but not LR(1)-conflict Robert.Corbett@Eng.Sun.COM (1995-02-04)
Re: LALR(1)- but not LR(1)-conflict frederic.tendeau@inria.fr (1995-02-09)
Re: LALR(1)- but not LR(1)-conflict ludemann@netcom.com (1995-02-12)
Re: LALR(1)- but not LR(1)-conflict adam@index.ping.dk (1995-02-18)
| List of all articles for this month |
Newsgroups: comp.compilers
From: adam@index.ping.dk (Adam Dickmeiss)
Keywords: parse, LR(1)
Organization: Index Data, Denmark.
References: 95-02-024
Date: Thu, 2 Feb 1995 12:51:00 GMT

holzmuel@kafka.informatik.uni-stuttgart.de (Bernd Holzmueller) writes:


>Does anybody know of a concrete example of an LALR(1)-conflict in an existing
>(or hypothetical but semantically meaningful) programming language grammar
>which is *exactly* LALR(1), i.e. the conflict is solved by moving to LR(1)?


This grammar is LR(1) but not LALR(1):


%term a b c d
%%
S: A a | b A c | B c | b B a
A: d
B: d
%%


There is a reduce/reduce conflict on rule "A -> d" and rule "B -> d" on
terminals a and c.


See Aho, et al.: "Compilers, Principles, Techniques, and Tools",
page 273, exercise 4.40.


-- Adam
--

Post a followup to this message

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