Re: predicate parsing

mauney@csljon.csl.ncsu.edu writes:
> 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 <tfj@apusapus.demon.co.uk> 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
work around)
--
Jon Mauney mauney@csc.ncsu.edu
Mauney Computer Consulting (919)828-8053
--

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