LL(*)

Christopher F Clark <christopher.f.clark@compiler-resources.com>
Sun, 20 Mar 2022 20:05:41 +0200

          From comp.compilers

Related articles
Parser LL(*) borucki.andrzej@gmail.com (Andy) (2022-03-18)
Re: Parser LL(*) gneuner2@comcast.net (George Neuner) (2022-03-19)
LL(*) christopher.f.clark@compiler-resources.com (Christopher F Clark) (2022-03-20)
Re: LL(*) gneuner2@comcast.net (George Neuner) (2022-03-21)
| List of all articles for this month |

From: Christopher F Clark <christopher.f.clark@compiler-resources.com>
Newsgroups: comp.compilers
Date: Sun, 20 Mar 2022 20:05:41 +0200
Organization: Compilers Central
References: 22-03-039 22-03-043
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="71474"; mail-complaints-to="abuse@iecc.com"
Keywords: parse, LL(1)
Posted-Date: 20 Mar 2022 15:12:12 EDT

George Neuner gets this right:


> Terence Parr both invented LL(*) and is the author of the ANTLR tool.
> AFAIK, Parr's own papers and books are the only sources of information
> about the method.


> >If is the simplest idea make LL(1) with several conflicts and first
> >speculative trying all paths, and backtrack?


> No, the simplest idea was LL(k) with a fixed value of 'k'. I don't
> believe Parr developed the method, but he was one of the pioneers of
> using it. Parr authored PCCTS which used LL(k), and early versions of
> ANTLR [prior to LL(*)] also used it.


> LL(*) eliminates the need for the developer to figure out what 'k' is
> optimal for the grammar: too low results in conflicts, too high may
> waste processing effort.


Terence's original paper, "Breaking the atomic k-tuple" made LL(k)
feasible, basically by doing each extra amount of lookahead 1 at a time.
Thus,LL(1) if no conflicts done, For those rules with LL(1) conflicts,
try LL(2), etc. No backtracking ever. No speculative execution either(*).
Just figure out how many tokens you need to read before you can
disambiguate which rule applies It is nearly always a fixed number.
If it isn't, the grammar is not LL(k) for any k. And, the if-then-else hack
takes care of one of the main problem cases where it isn't.


The latest version ANTLR4 does a slightly different variation on that,
by building a RTN that solves the problem. That's almost the same as
building an LR parser, but not quite. The only place one notices the
difference is when one has indirect (nested) left recursion. ANTLR4
doesn't allow that.


*) syntactic predicates are essentiaily speculative execution, but they
aren't strictly a part of LL(k)
--
******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------


Post a followup to this message

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