Skip to main content
edited body
Source Link
templatetypedef
  • 375.8k
  • 112
  • 954
  • 1.1k

Let's begin by constructing LR(1) configurating sets for the grammar:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bEb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 EF  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

Let's begin by constructing LR(1) configurating sets for the grammar:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bEb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 E  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

Let's begin by constructing LR(1) configurating sets for the grammar:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bEb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 F  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

edited body
Source Link
templatetypedef
  • 375.8k
  • 112
  • 954
  • 1.1k

Let's begin by constructing LR(1) configurating sets for the grammar:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bFbbEb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 E  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

Let's begin by constructing LR(1) configurating sets for the grammar:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bFb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 E  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

Let's begin by constructing LR(1) configurating sets for the grammar:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bEb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 E  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

Bounty Awarded with 50 reputation awarded by Jan Vorcak
deleted 1191 characters in body
Source Link
templatetypedef
  • 375.8k
  • 112
  • 954
  • 1.1k
 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bFb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> . e   [a]
 F  -> . e   [b]

 (4)
 S  -> aE.a [$]
 
 (5)
 S  -> aEa. [$]

 (6)
 S  -> aF.b [$]

 (7)
 S  -> aFb. [$]

 (8)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> e.    [b][a]
 F  -> e.    [a][b]

 (95)
 S  -> bFaE.a [$]
 
 (106)
 S  -> bFaaEa. [$]

 (117)
 S  -> bEaF.b [$]

 (128)
 S  -> bEbaFb. [$]

So I'm actually not convinced that this grammar is not LALR(1), because no two LR(1) configurating sets have the same core. Consequently, these are also the LALR(1) configurating sets. There aren't any shift/reduce conflicts anywhere, so this should be a valid LALR(1) parser.

To confirm that this is indeed correct, I had bison try operating on this file:

%%
S : 'a' E 'a' | 'a' F 'b' | 'b' F 'a' | 'b' E 'b';
E : ;
F : ;
%%

No shift/reduce conflicts were reported.

However, what I can say is that this grammar is not SLR(1). If we compute FOLLOW sets, we get the following:

FOLLOW(S) = {$}
FOLLOW(E) = {a, b}
FOLLOW(F9) = {a, b}

Given this, the SLR(1) configurating sets would be the same as the LR(1) sets, but with these lookaheads:

 (1)
S S' -> b.SFa [$]
 S  -> b.aEaEb [$]
 SE  -> .aFb [$]
 S e -> .bFa [$][b]
 SF  -> .bFb [$]

 (2)
 S'e -> S. [$][a]

 (310)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> e.    [a, b][b]
 FE  -> e.    [a, b][a]

 (411)
 S  -> aEbF.a [$]
 
 (512)
 S  -> aEabFa. [$]

 (613)
 S  -> aFbE.b [$]

 (714)
 S  -> aFbbEb. [$]
 

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (8)
 S  -> b.Fa [$]
 S  -> b.Eb4, [$]10)
 E  -> e.    [a, b]
 F  -> e.    [a, b]

 (9)
 S  -> bF.a [$]
 
 (10)
 S  -> bFa. [$]

 (11)
 S  -> bE.b [$]

 (12)
 S  -> bEb. [$]

Now, we have some shiftWhich now has a reduce/reduce conflicts, particularlyconflict in statesit (3all conflicts in LALR(1) and that weren't present in the LR(81) where thereparser are two reduce items (reducing E or F to/reduce, by the empty string with lookaheads a and bway).

Are you sure that This accounts for why the original question isn't to show that it'sgrammar is LR(1) but not SLR(1) or LALR(1) but not SLR(1)?.

Hope this helps!

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bFb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .    [a]
 F  -> .    [b]

 (4)
 S  -> aE.a [$]
 
 (5)
 S  -> aEa. [$]

 (6)
 S  -> aF.b [$]

 (7)
 S  -> aFb. [$]

 (8)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .    [b]
 F  -> .    [a]

 (9)
 S  -> bF.a [$]
 
 (10)
 S  -> bFa. [$]

 (11)
 S  -> bE.b [$]

 (12)
 S  -> bEb. [$]

So I'm actually not convinced that this grammar is not LALR(1), because no two LR(1) configurating sets have the same core. Consequently, these are also the LALR(1) configurating sets. There aren't any shift/reduce conflicts anywhere, so this should be a valid LALR(1) parser.

To confirm that this is indeed correct, I had bison try operating on this file:

%%
S : 'a' E 'a' | 'a' F 'b' | 'b' F 'a' | 'b' E 'b';
E : ;
F : ;
%%

No shift/reduce conflicts were reported.

However, what I can say is that this grammar is not SLR(1). If we compute FOLLOW sets, we get the following:

FOLLOW(S) = {$}
FOLLOW(E) = {a, b}
FOLLOW(F) = {a, b}

Given this, the SLR(1) configurating sets would be the same as the LR(1) sets, but with these lookaheads:

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bFb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .    [a, b]
 F  -> .    [a, b]

 (4)
 S  -> aE.a [$]
 
 (5)
 S  -> aEa. [$]

 (6)
 S  -> aF.b [$]

 (7)
 S  -> aFb. [$]
 
 (8)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .    [a, b]
 F  -> .    [a, b]

 (9)
 S  -> bF.a [$]
 
 (10)
 S  -> bFa. [$]

 (11)
 S  -> bE.b [$]

 (12)
 S  -> bEb. [$]

Now, we have some shift/reduce conflicts, particularly in states (3) and (8) where there are two reduce items (reducing E or F to the empty string with lookaheads a and b).

Are you sure that the original question isn't to show that it's LR(1) but not SLR(1) or LALR(1) but not SLR(1)?

 (1)
 S' -> .S [$]
 S  -> .aEa [$]
 S  -> .aFb [$]
 S  -> .bFa [$]
 S  -> .bFb [$]

 (2)
 S' -> S. [$]

 (3)
 S  -> a.Ea [$]
 S  -> a.Fb [$]
 E  -> .e   [a]
 F  -> .e   [b]

 (4)
 E  -> e.   [a]
 F  -> e.   [b]

 (5)
 S  -> aE.a [$]
 
 (6)
 S  -> aEa. [$]

 (7)
 S  -> aF.b [$]

 (8)
 S  -> aFb. [$]

 (9)
 S  -> b.Fa [$]
 S  -> b.Eb [$]
 E  -> .e   [b]
 F  -> .e   [a]

 (10)
 E  -> e.   [b]
 E  -> e.   [a]

 (11)
 S  -> bF.a [$]
 
 (12)
 S  -> bFa. [$]

 (13)
 S  -> bE.b [$]

 (14)
 S  -> bEb. [$]

If you'll notice, states (4) and (10) have the same core, so in the LALR(1) automaton we'd merge them together to form the new state

 (4, 10)
 E -> e. [a, b]
 F -> e. [a, b]

Which now has a reduce/reduce conflict in it (all conflicts in LALR(1) that weren't present in the LR(1) parser are reduce/reduce, by the way). This accounts for why the grammar is LR(1) but not LALR(1).

Hope this helps!

added 225 characters in body
Source Link
templatetypedef
  • 375.8k
  • 112
  • 954
  • 1.1k
Loading
Source Link
templatetypedef
  • 375.8k
  • 112
  • 954
  • 1.1k
Loading