Related articles |
---|
Parser generators which implemented Burke-Fisher error correction momonjar@gmail.com (Momonjar) (2007-04-18) |
Re: Parser generators which implemented Burke-Fisher error correction gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-04-19) |
Re: Parser generators which implemented Burke-Fisher error correction monnier@iro.umontreal.ca (Stefan Monnier) (2007-04-20) |
From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
Newsgroups: | comp.compilers |
Date: | 19 Apr 2007 00:22:27 -0400 |
Organization: | Compilers Central |
References: | 07-04-064 |
Keywords: | parse, errors |
Posted-Date: | 19 Apr 2007 00:22:27 EDT |
Our moderator wrote:
> [Back when we punched our programs on cards, handed the decks to the
> operator, and got printouts back an hour later, error correction was
> very popular since it offered the chance to find more bugs per run and
> decrease the number of runs until your program worked. Now that we do
> everything interactively, I don't see much point in the compiler
> guessing what you wanted to do rather than just point out where the
> error is and letting you fix it. -John]
Mostly I agree, but in some cases one mistake can propagate into
a large number of problems later, especially from declarations
statements. A mistake in one declaration might cause all the
rest on the same statement to be ignored, when it would be easy for
the compiler to find the others.
Even with interactive debugging, it is nice to find and fix more
than one error each cycle. That depends on the compiler at least
figuring out where the next statement starts, and usually a little
more.
-- glen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.