Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1322

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

From wclodius@earthlink.net (William Clodius)
Newsgroups comp.compilers
Subject Re: LR(1) Parsing : Error Handling & Recovery
Date 2014-07-18 13:41 -0600
Organization Compilers Central
Message-ID <14-07-032@comp.compilers> (permalink)
References <14-07-023@comp.compilers> <14-07-024@comp.compilers> <14-07-026@comp.compilers> <14-07-027@comp.compilers> <14-07-029@comp.compilers>

Show all headers | View raw

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]

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

LR(1) Parsing : Error Handling & Recovery Seima Rao <seimarao@gmail.com> - 2014-07-10 05:30 +0530
  Re: LR(1) Parsing : Error Handling & Recovery Ivan Godard <ivan@ootbcomp.com> - 2014-07-16 16:39 -0400
    Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-07-17 20:15 +0300
      Re: LR(1) Parsing : Error Handling & Recovery Ivan Godard <ivan@ootbcomp.com> - 2014-07-17 13:03 -0700
        Re: LR(1) Parsing : Error Handling & Recovery Ivan Godard <ivan@ootbcomp.com> - 2014-07-17 13:57 -0700
          Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-18 13:41 -0600
            Re: LR(1) Parsing : Error Handling & Recovery Stefan Monnier <monnier@iro.umontreal.ca> - 2014-07-18 21:09 -0400
              Re: LR(1) Parsing : Error Handling & Recovery Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2014-07-19 12:04 +0200
                Re: LR(1) Parsing : Error Handling & Recovery Stefan Monnier <monnier@iro.umontreal.ca> - 2014-07-20 10:28 -0400
                Re: LR(1) Parsing : Error Handling & Recovery Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2014-07-21 10:46 +0200
                Re: LR(1) Parsing : Error Handling & Recovery Stefan Monnier <monnier@iro.umontreal.ca> - 2014-08-06 21:32 -0400
            Re: LR(1) Parsing : Error Handling & Recovery arnold@skeeve.com (Aharon Robbins) - 2014-07-20 06:05 +0000
    Re: LR(1) Parsing : Error Handling & Recovery George Neuner <gneuner2@comcast.net> - 2014-07-17 18:49 -0400
      Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-18 13:41 -0600
        Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-07-19 15:29 +0200
          Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-07-20 00:40 +0300
            Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-07-20 01:38 +0200
              Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-07-21 15:20 +0300
                Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-07-21 18:39 +0200
                Re: LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-08-26 13:44 +0300
                Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-08-29 11:13 +0200
                Re: split tokens; was LR(1) Parsing : Error Handling & Recovery Evangelos Drikos <drikosev@otenet.gr> - 2014-09-03 16:57 +0300
                Re: LR(1) Parsing : Error Handling & Recovery Hans Aberg <haberg-news@telia.com> - 2014-09-03 19:07 +0200
        Re: LR(1) Parsing : Error Handling & Recovery George Neuner <gneuner2@comcast.net> - 2014-07-20 01:19 -0400
          Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-20 21:43 -0600
            Re: LR(1) Parsing : Error Handling & Recovery wclodius@earthlink.net (William Clodius) - 2014-07-21 21:44 -0600
          Re: LR(1) Parsing : Error Handling & Recovery Chris Dodd <cdodd@acm.org> - 2014-07-21 06:07 +0000
            Re: LR(1) Parsing : Error Handling & Recovery George Neuner <gneuner2@comcast.net> - 2014-07-25 21:58 -0400
              Re: LR(1) Parsing : Error Handling & Recovery Chris Dodd <cdodd@acm.org> - 2014-07-26 21:16 +0000
                Re: LR(1) Parsing : Error Handling & Recovery Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2014-07-28 14:43 +0200
                Re: LR(1) Parsing : Error Handling & Recovery Chris Dodd <cdodd@acm.org> - 2014-07-29 19:38 +0000
  Re: LR(1) Parsing : Error Handling & Recovery Eric <news@fx29.iad.highwinds-media.com> - 2014-07-16 16:40 -0400

csiph-web