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

Groups > comp.compilers > #3671 > unrolled thread

paper: Towards Automatic Error Recovery in Parsing Expression

Back to article view | Back to comp.compilers

Contents

  paper: Towards Automatic Error Recovery in Parsing Expression John R Levine <johnl@taugh.com> - 2025-07-08 20:59 -0400
    Re: paper: Towards Automatic Error Recovery in Parsing Expression Kaz Kylheku <643-408-1753@kylheku.com> - 2025-07-09 04:33 +0000
      Re: paper: Towards Automatic Error Recovery in Parsing Expression cross@spitfire.i.gajendra.net - 2025-07-11 11:33 +0000

#3671 — paper: Towards Automatic Error Recovery in Parsing Expression

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

[toc] | [next] | [standalone]

#3672

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

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

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[It's a little more complicated than that.  Sometimes you cut and paste
code, or you import a file of code from somewhere.  But I agree that a
plausible approach is to stop at the first error and say fix it. -John]

[toc] | [prev] | [next] | [standalone]

#3674

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web