From Newsgroup: comp.compilers

Lots of compilers tried to do error recovery back in the batch era, but
it fell out of favor until IDEs tried to build parse trees out of less
than perfect source code.

Abstract

Error recovery is an essential feature for a parser that should be plugged
in Integrated Development Environments (IDEs), which must build Abstract
Syntax Trees (ASTs) even for syntactically invalid programs in order to
offer features such as automated refactoring and code completion.
Parsing Expressions Grammars (PEGs) are a formalism that naturally
describes recursive top-down parsers using a restricted form of
backtracking. Labeled failures are a conservative extension of PEGs that
adds an error reporting mechanism for PEG parsers, and these labels can
also be associated with recovery expressions to also be an error recovery mechanism. These expressions can use the full expressivity of PEGs to
recover from syntactic errors.
Manually annotating a large grammar with labels and recovery expressions
can be difficult. In this work, we present an algorithm that automatically annotates a PEG with labels, and builds their corresponding recovery expressions. We evaluate this algorithm by adding error recovery to the
parser of the Titan programming language. The results shown that with a
small amount of manual intervention our algorithm can be used to produce
error recovering parsers for PEGs where most of the alternatives are
disjoint.

https://arxiv.org/abs/2507.03629

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.compilers

In article <25-07-005@comp.compilers>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2025-07-09, John R Levine <johnl@taugh.com> quoted:

Error recovery is an essential feature for a parser that should be plugged >> in Integrated Development Environments (IDEs), which must build Abstract

I am deeply skeptical. Error recovery is essential when you're handing
a deck of punched cards to a job submission window.

A compiler integrated into an IDE can stop at the first error,
put the cursor there and so it goes.

The IDE can always be compiling as you type each character, so that most
of the time there are no errors in the code. The only time an error
occurs is when you type something malformed or not yet complete, and
that is happening exactly in one place: where the cursor is in the
file that has the current editing focus. The situation is flagged
as you type so you fix it

Sadly, this sounds more aspirational than reflective of actual
pratice today.

One may have a perfectly fine program that one loads into one's IDE
(or, increasingly, more traditional text editor augmented with an
external language server that it communicates with via an RPC
protocol), but one hasn't (yet!) set up the environment so that the
code actually compiles. As a trivial example, one might need to
configure the path to a set of prerequisite libraries, or install a
dependency, or something similarly mundane, before the code will
actually build. The editor choking at that point is not useful.

If your refactoring tools are producing bad code, the tools need
to be repaired.

Caveat that I'm not done reading the paper, but I am not sure that was
the issue. I think it has more to do with things like supporting
syntax highlighting and cross-referencing. A missing semi-colon that
caused syntax highlighting in the rest of the file to fail is kind of
a bummer.

- Dan C.
--- Synchronet 3.21b-Linux NewsLink 1.2