Re: LR(k)-Parser wanted

Terence John Parr <>
Sun, 30 Apr 1995 04:24:24 GMT

          From comp.compilers

Related articles
LR(k)-Parser wanted (1995-04-21)
Re: LR(k)-Parser wanted (1995-04-29)
Re: LR(k)-Parser wanted (1995-04-25)
Re: LR(k)-Parser wanted (Terence John Parr) (1995-04-30)
Re: LR(k)-Parser wanted (Bob Buckley) (1995-05-11)
Re: LR(k)-Parser wanted (1995-06-05)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Terence John Parr <>
Keywords: parse
Organization: Compilers Central
Date: Sun, 30 Apr 1995 04:24:24 GMT

Josef Grosch at CoCoLab writes:
> Also, I started to work on an LR(k) version of 'lark'. It should be called
> partial LR(k), because again LALR(1) is used by default and LR(k) only where
> necessary.

Have you finished or still working on it?

> It tries LR(2), LR(3), etc. up to a given limit. Before trying
> LR(k) an approximation of LR(k) is tried which is much more efficient to
> compute.

This wouldn't happen to be the linear approximate lookahead described
in my thesis and used in ANTLR would it? Just curious to see if
anybody had deciphered my thesis yet ;)

> Again, conventional LR(k) for a even few states is expensive.
> The analysis phase is more or less completed. A grammar for COBOL with more
> than 100 LR(1) conflicts can be analyzed giving the result that half of
> the conflicts can be solved using LR(2).

I'm glad people are starting to realize the value of (and implement) parsers
with k>1.

> The generation of parsers that
> automatically use more than one lookahead token has to be finished.

Ah. Ok. Keep up the good work.

PS FYI, the thesis was Purdue EE 1993

"Obtaining Practical Variants of LL(k) and LR(k) for k>1
By Splitting the Atomic k-tuple"

Post a followup to this message

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