Re: LR(1) Parsing : Error Handling & Recovery

wclodius@earthlink.net (William Clodius)
Fri, 18 Jul 2014 13:41:52 -0600

          From comp.compilers

Related articles
[2 earlier articles]
Re: LR(1) Parsing : Error Handling & Recovery news@fx29.iad.highwinds-media.com (Eric) (2014-07-16)
Re: LR(1) Parsing : Error Handling & Recovery drikosev@otenet.gr (Evangelos Drikos) (2014-07-17)
Re: LR(1) Parsing : Error Handling & Recovery ivan@ootbcomp.com (Ivan Godard) (2014-07-17)
Re: LR(1) Parsing : Error Handling & Recovery ivan@ootbcomp.com (Ivan Godard) (2014-07-17)
Re: LR(1) Parsing : Error Handling & Recovery gneuner2@comcast.net (George Neuner) (2014-07-17)
Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (2014-07-18)
Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (2014-07-18)
Re: LR(1) Parsing : Error Handling & Recovery monnier@iro.umontreal.ca (Stefan Monnier) (2014-07-18)
Re: LR(1) Parsing : Error Handling & Recovery DrDiettrich1@aol.com (Hans-Peter Diettrich) (2014-07-19)
Re: LR(1) Parsing : Error Handling & Recovery haberg-news@telia.com (Hans Aberg) (2014-07-19)
Re: LR(1) Parsing : Error Handling & Recovery drikosev@otenet.gr (Evangelos Drikos) (2014-07-20)
Re: LR(1) Parsing : Error Handling & Recovery haberg-news@telia.com (Hans Aberg) (2014-07-20)
Re: LR(1) Parsing : Error Handling & Recovery gneuner2@comcast.net (George Neuner) (2014-07-20)
[16 later articles]
| List of all articles for this month |

From: wclodius@earthlink.net (William Clodius)
Newsgroups: comp.compilers
Date: Fri, 18 Jul 2014 13:41:52 -0600
Organization: Compilers Central
References: 14-07-023 14-07-024 14-07-026 14-07-027 14-07-029
Keywords: parse, LL(1), comment
Posted-Date: 18 Jul 2014 16:06:22 EDT

Ivan Godard <ivan@ootbcomp.com> wrote:


> <snip>
>
> [Error rules in yacc parsers are really for error recovery, not error
> reporting. They let the parser resynchronize at a boundary such as a
> semicolon between statements. LALR can only tell you that the parse
> failed, and it can give you a set of tokens that would be valid where
> the parse failed, but that set is often too large due to the way the
> states are created. It's certainly easier to produce diagnostics in a
> RD parser. What's hard is to verify that the language it accepts is
> the language you want, and that it correctly catches any invalid
> input. -John]
This sort of comment has appeared frequently in the past and to some
extent I find it puzzing. A recursive descent translation of an LL(k)
(with k small) grammar is straightforward, and should readilly match the
grammar, and give you the parse you desire. Is the problem that error
recognition generally does not readily map to the desired grammar, or
that the usual "on the fly" semantic anayisis in such implementations
loses context, or something else I haven't recognized?


[The practical problem is that RD parsers are typically written by
hand, and after a couple of tweaks to the grammar and what are
supposed to be matching tweaks to the code, they can get out of sync.
Also, error checking code is boring and one's eyes tend to glaze. An
RD parser mechanically generated from the grammar should reflect the
grammar as accurately as any other mechanically generated parser.
-John]


Post a followup to this message

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