|LL Parser problem email@example.com (2004-08-09)|
|Re: LL Parser problem firstname.lastname@example.org (2004-08-10)|
|Re: LL Parser problem email@example.com (SM Ryan) (2004-08-11)|
|Re: LL Parser problem firstname.lastname@example.org (Nick Roberts) (2004-08-13)|
|Re: LL Parser problem cfc@shell01.TheWorld.com (Chris F Clark) (2004-08-15)|
|Re: LL Parser problem email@example.com (Nick Roberts) (2004-08-23)|
|Re: LL Parser problem firstname.lastname@example.org (Richard Pennington) (2004-08-25)|
|Re: LL Parser problem email@example.com (2004-09-03)|
|Re: LL Parser problem cfc@shell01.TheWorld.com (Chris F Clark) (2004-09-07)|
|From:||"Nick Roberts" <firstname.lastname@example.org>|
|Date:||13 Aug 2004 17:31:26 -0400|
|Posted-Date:||13 Aug 2004 17:31:26 EDT|
On 11 Aug 2004 12:53:27 -0400, SM Ryan <email@example.com> wrote:
> firstname.lastname@example.org (Jared Lessl) wrote:
> # > [Special case the lexer to return a mutant < token after an array
> # > name. -John]
> # Except that in AREV, any variable or function return value can be an
> # array of this type. The only assurance I can have that a '<' is not
> # an array index is if it immediately follows a literal or numerical
> # value.
> If you have two different derivations
> Z -> X -> A<B>
> and Z -> Y -> A<B
> where B has an unbounded expansion, then it isn't LL(k). To be LL(k) you
> have to be able choose X or Y by left context + at most k symbols. In
> this case you have traverse the entire expansion of B which can be more
> than k symbols.
I humbly suggest, if you have the option, that you switch to using a
backtracking parser (as hinted at by your own comment). It may not be
so quick, but I suspect that's not likely to be a problem.
It seems to raise a bigger question, to my mind. Are, perhaps, all
these limited grammar parsers (parser generators) -- LL(1), LL(k),
LALR, and so on -- losing their relevance these days (at least with
regards to programming language compilers and similar tools)?
[Good question. C++ needs a backtracking parser, but I get the impression
that was a mistake. -John]
Return to the
Search the comp.compilers archives again.