Re: Preview in grammar

haberg@math.su.se (Hans Aberg)
9 May 2006 00:48:50 -0400

          From comp.compilers

Related articles
Preview in grammar franku@fmi.uni-passau.de (Ulrich Frank) (2006-05-03)
Re: Preview in grammar marcov@stack.nl (Marco van de Voort) (2006-05-04)
Re: Preview in grammar haberg@math.su.se (2006-05-04)
Re: Preview in grammar pbmann@gmail.com (2006-05-09)
Re: Preview in grammar haberg@math.su.se (2006-05-09)
Re: Preview in grammar DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-09)
Re: Preview in grammar franku@fmi.uni-passau.de (Ulrich Frank) (2006-05-09)
Re: Preview in grammar cfc@shell01.TheWorld.com (Chris F Clark) (2006-05-11)
Re: Preview in grammar franku@fmi.uni-passau.de (Ulrich Frank) (2006-05-11)
Re: Preview in grammar franku@fmi.uni-passau.de (Ulrich Frank) (2006-05-11)
Re: Preview in grammar Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2006-05-12)
[5 later articles]
| List of all articles for this month |

From: haberg@math.su.se (Hans Aberg)
Newsgroups: comp.compilers
Date: 9 May 2006 00:48:50 -0400
Organization: Mathematics
References: 06-05-011 06-05-015
Keywords: parse, LR(1)
Posted-Date: 09 May 2006 00:48:50 EDT

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


Post a followup to this message

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