|[11 earlier articles]|
|Re: Compiler Compiler Compiler firstname.lastname@example.org (Matthias Blume) (2001-03-31)|
|Re: compiler compiler compiler email@example.com (Toon Moene) (2001-03-31)|
|Re: Compiler Compiler Compiler firstname.lastname@example.org (Joachim Durchholz) (2001-04-04)|
|Re: compiler compiler compiler email@example.com (2001-04-04)|
|Re: Compiler Compiler Compiler firstname.lastname@example.org (Ira D. Baxter) (2001-04-10)|
|Re: Compiler Compiler Compiler email@example.com (Chris F Clark) (2001-04-10)|
|Re: Compiler Compiler Compiler firstname.lastname@example.org (2001-04-10)|
|From:||email@example.com (Henry Spencer)|
|Date:||10 Apr 2001 01:48:25 -0400|
|Organization:||SP Systems, Toronto, Canada|
|References:||01-03-095 01-03-122 01-04-026|
|Posted-Date:||10 Apr 2001 01:48:25 EDT|
Joachim Durchholz <firstname.lastname@example.org> wrote:
>There are other differences that might be more relevant.
>For example, LL parsers have been consistently reported to produce
>better error reporting. Does anybody know whether that's a historic
>accident, or is there something in LL parsing that makes it inherently
>easier to add useful error actions to LL parsers?
In a general sense, LL parsing inherently has an easier time with
error handling, because a top-down parse intrinsically knows much more
about the *context* of an error. The parser knows exactly what it
thought it was parsing, and how that was supposed to fit into the
surroundings, whereas a bottom-up parser is more or less discovering
this as it goes.
(This doesn't mean that any particular LL parsing tool makes error
handling easy, mind you.)
This knowledge of context is also why semantics are often easier to fit
into LL. The flip side, of course, is more limited parsing power, because
LL can handle only grammars where it *can* sort out the exact context in
advance. LR, which discovers what's going on along the way, can deal with
constructs whose overall plan has to be figured out gradually.
When failure is not an option, success | Henry Spencer email@example.com
can get expensive. -- Peter Stibrany | (aka firstname.lastname@example.org)
Return to the
Search the comp.compilers archives again.