Re: LL(*)

George Neuner <gneuner2@comcast.net>
Mon, 21 Mar 2022 15:47:54 -0400

          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: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Mon, 21 Mar 2022 15:47:54 -0400
Organization: A noiseless patient Spider
References: 22-03-039 22-03-043 22-03-045
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="7768"; mail-complaints-to="abuse@iecc.com"
Keywords: LL(1)
Posted-Date: 21 Mar 2022 15:52:50 EDT

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


>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.


So Parr did invent a way to make fixed 'k' more practical to use. I
was not aware of that - thank you.




>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)


ANTLR also has so-called "semantic" predicates which can invoke user
supplied functions and continue with or fail the current rule based on
the results.


George


Post a followup to this message

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