|predicate parsing email@example.com (Ariel Meir Tamches) (1993-04-21)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-22)|
|predicate parsing email@example.com (Stephen J Bevan) (1993-04-22)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-23)|
|Re: predicate parsing email@example.com (1993-04-23)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-27)|
|Re: predicate parsing email@example.com (1993-04-28)|
|predicate parsing firstname.lastname@example.org (Trevor Jenkins) (1993-04-28)|
|Re: predicate parsing email@example.com (1993-04-29)|
|Re: predicate parsing firstname.lastname@example.org (1993-04-29)|
|Re: predicate parsing email@example.com (1993-04-30)|
|From:||Trevor Jenkins <firstname.lastname@example.org>|
|Organization:||Job hunters use Parachute|
|Date:||Wed, 28 Apr 1993 22:43:28 GMT|
> A) LL parsers can be as fast as anything else.
Indeed Fraser and ? at Bell Labs wrote a recursive descent (LL(1)) based
parser for their new C compiler. (from memory) They said "LALR parsers (ie
yacc generated ones) are too slow".
> 2) LL Parsers are to be *preferred* when repair is an issue.
> The simple structure of the data on the stacks makes life
> much easier.
It is generally acknowledged that in an LR based parser error recovery is
real messy. As to the data on the stack that has nothing to do with the
error recovery procedure of either LL or LR parsers.
> I'm not going to stick my neck out on III, however.
I'm not a C++ theologian but both of you seem to be confusing language
with grammar. Just because a language is described by an *LR(1) grammar
soes not necessarily mean that it the LANGUAGE is not LL(1). If it can be
described by an LL(1) grammar but the langauge designer decides to publish
a grammar in the LR family that is there choice but does not restict an
implementation to using that grammar form.
134 Frankland Rd, Croxley Green, RICKMANSWORTH, WD3 3AU, England
email: email@example.com phone: +44 (0)923 776436 radio: G6AJG
Return to the
Search the comp.compilers archives again.