Related articles |
---|
LR Parser Combinator? alex.rubinsteyn@gmail.com (Alex Rubinsteyn) (2007-05-11) |
Re: LR Parser Combinator? torbenm@app-2.diku.dk (2007-05-15) |
Re: LR Parser Combinator? schmitz@i3s.unice.fr (Sylvain Schmitz) (2007-05-16) |
From: | torbenm@app-2.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen) |
Newsgroups: | comp.compilers |
Date: | Tue, 15 May 2007 10:33:14 +0200 |
Organization: | Department of Computer Science, University of Copenhagen |
References: | 07-05-042 |
Keywords: | parse |
Posted-Date: | 16 May 2007 03:03:51 EDT |
Alex Rubinsteyn <alex.rubinsteyn@gmail.com> writes:
> Is it possible to compose LR(k) shift/reduce parsers the same way
> LL(k) parsers are combined in libraries like Parsec? Has this been
> implemented before?
You could make parser combinators that at runtime would build up a
representation of a grammar (with actions) that can subsequently (at
runtime) be converted to a parse table which is then used for the
actual parsing. So, unlike LL parser combinators, there is a staging
of the process. To avoid choking on conflicts, you can backtrack or
use GLR parsing.
I suppose you could make the generation of the parse table lazy,
generating the entries as you need them, thus avoiding a time and
space consuming initial generation stage at the cost of slower parsing
initially (until you have most of the table entries you need). A bit
like JIT versus traditional compilation.
I'm not aware of any implementations, but I haven't looked very hard.
Torben
Return to the
comp.compilers page.
Search the
comp.compilers archives again.