Re: Preview in grammar

pbmann@gmail.com
9 May 2006 00:47:47 -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)
[6 later articles]
| List of all articles for this month |

From: pbmann@gmail.com
Newsgroups: comp.compilers
Date: 9 May 2006 00:47:47 -0400
Organization: Compilers Central
References: 06-05-011
Keywords: parse, LR(1)
Posted-Date: 09 May 2006 00:47:47 EDT

Ulrich Frank wrote:
> Hello NG,
>
> for my thesis I need a parser generator for generating a parser for a
> language similar to OQL (Object Query Language). I already found a lot
> of parser generators in the web or books but I need a special
> functionality which is not provided by every generated parser. Namely
> I need a preview which token comes next in an uncomplete input string.
> For example when you type "select abc" the preview would be "from". Or
> in "select abc from def where abc" the preview would be "<, <=, >, >=,
> equals".
>


LALR parsers can do what you want, but it involves an extra stack
which keeps track of the states already seen when a reduction takes
place (or something like that). I used to provide it with my older
product LALR 5.0.


The parser needs to simulate an error condition, then undo all
reductions, then do a trial parse for all terminal symbols in the
grammar, keeping track of which symbols enable a valid transition to a
next state. This symbol list is what you want.


Of course, canonical LR(1) is better because you have all the
information you need at the encounter of the simulated error in the
current state.


Paul Mann
http://parsetec.com



Post a followup to this message

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