Re: Preview in grammar

John Levine wrote:


>>> for my thesis I need a parser generator ... I need a preview which token
>>> comes next in an uncomplete input string.


>> LALR(1) is not suitable, because it merges the LR(1) states in a way
that the
>> lookahead tokens may be put on some action coming up later on in the
parsing.


> Good point, LALR has never been great for error reporting.


It is funny that the need for LR(1) over LALR(1) may come not from the
need of covering more grammars, but from this lookahead problem, as
well as better error reporting. (Bison should probably have LR(1)
sometime in the future.)


Another idea that comes to my mind is propping up LALR(1) so as to
synthesizing LR(1) lookahead/error reporting. A difference between
LALR(1) and LR(1) is that when an error token shows up, the latter
reports it immediately, but in the former, although no further tokens
will be read, some reductions might be performed before the error is
discovered. One might then to each LALR(1) state add a list of valid
tokens, alternatively error tokens. The idea in the case of error
reporting would be to then use this error token list to discover the
error as soon as the error token shows up in the input. This list
could then also be used to indicate the complement set of valid
tokens.


--
    Hans Aberg

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