Re: Using bison without Flex

[John R. Levine]

> > 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