|[2 earlier articles]|
|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:||firstname.lastname@example.org (Jon Mauney)|
|Date:||Thu, 29 Apr 1993 12:59:05 GMT|
> 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.
Trevor Jenkins <email@example.com> writes:
>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.
Having implemented error-repair for both LL and LR parsers, I must
disagree. Since the parse stack contains the definition of the valid
continuations of the input, I consider it to be essential to good error
repair. Even quick and dirty panic-mode recovery methods look at the
stack to the extent of skipping input to a symbol that can be read, and/or
popping to a configuration that can read the current symbol.
>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.
Being a proponent of LL parsing, I frequently make the same speech to
people who state that X cannot be done with LL(1). In this case, however,
numerous people have complained about the difficulty in writing an LALR
grammar for C++. Not having tried it myself (yet), I'm not going to claim
that it is easy to do with LL. ( In theory, of course, C++ contains the
dangling-else problem and is not an LL language. But that one is easy to
Jon Mauney firstname.lastname@example.org
Mauney Computer Consulting (919)828-8053
Return to the
Search the comp.compilers archives again.