|LR(k)-Parser wanted email@example.com (1995-04-21)|
|Re: LR(k)-Parser wanted firstname.lastname@example.org (1995-04-29)|
|Re: LR(k)-Parser wanted email@example.com (1995-04-25)|
|Re: LR(k)-Parser wanted firstname.lastname@example.org (Terence John Parr) (1995-04-30)|
|Re: LR(k)-Parser wanted email@example.com (Bob Buckley) (1995-05-11)|
|Re: LR(k)-Parser wanted firstname.lastname@example.org (1995-06-05)|
|From:||Terence John Parr <email@example.com>|
|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
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
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
> 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"
Return to the
Search the comp.compilers archives again.