You might have to resolve that using GLR, or the hack that a
reduce/reduce conflict is resolved in favor of the earlier rule in the
bison script:
whilekwd: 'w' 'h' 'i' 'l' 'e' ;
ifkwd: 'i' 'f' ;
thenkwd: 't' 'h' 'e' 'n' ;
elsekwd: 'e' 'l' 's' 'e' ;
identifier: letter | identifier letter ;
letter: 'a' | 'b' | 'c' ... 'z’ ;
A problem here is that the lexer scans forward to find the whole
identifier - it must, otherwise it will miss names like “ifs”. When the
non-GLR parser sees the “if”, it will take it.
That depends on the rest of the grammar. If the follow set for the ifkwd
rule doesn't contain 's', which it probably won't, then the ifkwd rule
won't be reduced and the identifier rule will consume that input.
Bison can handle all sorts of ambiguity while shifting so long as it
doesn't have to look more than one token ahead when it's time to reduce a
rule.
Then, when the lexer finds it cannot scan forward anymore, by a
character or EOS, it takes the longest match according to some rules and
puts the rest stuff back into the stream for rescanning.
That's not how flex works, unless you use the uncommon '/' trailing
context operator. It turns all of the patterns into a DFA and uses that
to match the input, not normally looking more than one character ahead.
The DFA that bison creates to do shifting should be able to do anything
that the flex DFA can do.
R's,
John
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
