Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1350
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: LR(1) Parsing : Error Handling & Recovery |
| Date | 2014-07-25 21:58 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <14-07-060@comp.compilers> (permalink) |
| References | (1 earlier) <14-07-024@comp.compilers> <14-07-030@comp.compilers> <14-07-031@comp.compilers> <14-07-041@comp.compilers> <14-07-046@comp.compilers> |
On Mon, 21 Jul 2014 06:07:55 +0000 (UTC), Chris Dodd <cdodd@acm.org>
wrote:
>George Neuner <gneuner2@comcast.net> wrote in news:14-07-041@comp.compilers:
>> LL(k) always can be refactored to single token lookahead, but it
>> causes an explosion of grammar states. E.g., given a single LL(3)
>> rule, an equivalent set of LL(1) rules must match every valid
>> combination of tokens at +1, +2 and +3.
>
>Not true -- LL(k+1) languages are a strict superset of LL(k) languages, so
>there exist LL(k) grammars that cannot be refactored to a smaller k.
Yes and no.
For every LL(k) grammar where both k and the set T of tokens is fixed,
there is an equivalent LL(1) grammar. In the worst case, the
equivalent LL(1) grammar will have k**T rules.
Only where k or T is unbounded, so that the power set of {n:1<=n<=k}
lookahead tokens for some rule is not enumerable, can you not derive
an equivalent in LL(1).
The problem is that an LL({n:1<n<=k}) rule explodes multiplicatively
into an n-level tree of LL(1) rules, with each branch at each level
m<=n having to cover follow(m).
Meaning that it is effectively unworkable for any but small k.
Fortunately, for any reasonable LL(k>1) grammar, k will be bounded and
small, and the grammar will contain just a handful of rules requiring
the maximum k lookahead. Most rules will be LL({n:1<=n<k}) where n is
very small.
George
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
LR(1) Parsing : Error Handling & Recovery Seima Rao <seimarao@gmail.com> - 2014-07-10 05:30 +0530
Re: LR(1) Parsing : Error Handling & Recovery Ivan Godard <ivan@ootbcomp.com> - 2014-07-16 16:39 -0400
Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-07-17 20:15 +0300
Re: LR(1) Parsing : Error Handling & Recovery Ivan Godard <ivan@ootbcomp.com> - 2014-07-17 13:03 -0700
Re: LR(1) Parsing : Error Handling & Recovery Ivan Godard <ivan@ootbcomp.com> - 2014-07-17 13:57 -0700
Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-18 13:41 -0600
Re: LR(1) Parsing : Error Handling & Recovery Stefan Monnier <monnier@iro.umontreal.ca> - 2014-07-18 21:09 -0400
Re: LR(1) Parsing : Error Handling & Recovery Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2014-07-19 12:04 +0200
Re: LR(1) Parsing : Error Handling & Recovery Stefan Monnier <monnier@iro.umontreal.ca> - 2014-07-20 10:28 -0400
Re: LR(1) Parsing : Error Handling & Recovery Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2014-07-21 10:46 +0200
Re: LR(1) Parsing : Error Handling & Recovery Stefan Monnier <monnier@iro.umontreal.ca> - 2014-08-06 21:32 -0400
Re: LR(1) Parsing : Error Handling & Recovery arnold@skeeve.com (Aharon Robbins) - 2014-07-20 06:05 +0000
Re: LR(1) Parsing : Error Handling & Recovery George Neuner <gneuner2@comcast.net> - 2014-07-17 18:49 -0400
Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-18 13:41 -0600
Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-07-19 15:29 +0200
Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-07-20 00:40 +0300
Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-07-20 01:38 +0200
Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-07-21 15:20 +0300
Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-07-21 18:39 +0200
Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-08-26 13:44 +0300
Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-08-29 11:13 +0200
Re: split tokens; was LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-09-03 16:57 +0300
Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-09-03 19:07 +0200
Re: LR(1) Parsing : Error Handling & Recovery George Neuner <gneuner2@comcast.net> - 2014-07-20 01:19 -0400
Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-20 21:43 -0600
Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-21 21:44 -0600
Re: LR(1) Parsing : Error Handling & Recovery Chris Dodd <cdodd@acm.org> - 2014-07-21 06:07 +0000
Re: LR(1) Parsing : Error Handling & Recovery George Neuner <gneuner2@comcast.net> - 2014-07-25 21:58 -0400
Re: LR(1) Parsing : Error Handling & Recovery Chris Dodd <cdodd@acm.org> - 2014-07-26 21:16 +0000
Re: LR(1) Parsing : Error Handling & Recovery Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2014-07-28 14:43 +0200
Re: LR(1) Parsing : Error Handling & Recovery Chris Dodd <cdodd@acm.org> - 2014-07-29 19:38 +0000
Re: LR(1) Parsing : Error Handling & Recovery Eric <news@fx29.iad.highwinds-media.com> - 2014-07-16 16:40 -0400
csiph-web