Re: LR(k)-Parser wanted

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.


Regards,
Terence
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"


ftp://ftp.parr-research.com/pub/pccts/parr.phd.thesis.ps.gz
--

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