Re: More intellegent error reporting than 'parse error' with Bison

Carl Cerecke <cdc@maxnet.co.nz>
13 Oct 2003 15:24:59 -0400

          From comp.compilers

Related articles
More intellegent error reporting than 'parse error' with Bison tergiver@msn.com (2003-10-13)
Re: More intellegent error reporting than 'parse error' with Bison cdc@maxnet.co.nz (Carl Cerecke) (2003-10-13)
Re: More intellegent error reporting than 'parse error' with Bison nr@labrador.eecs.harvard.edu (2003-10-31)
| List of all articles for this month |

From: Carl Cerecke <cdc@maxnet.co.nz>
Newsgroups: comp.compilers
Date: 13 Oct 2003 15:24:59 -0400
Organization: TelstraClear
References: 03-10-066
Keywords: parse, errors, LALR
Posted-Date: 13 Oct 2003 15:24:59 EDT

> [Look through the archives. This question has come up a lot, without many
> useful answers. LALR parsers do a fine job on correct input, but on
> incorrect input they tend to throw up their hands unless you put in lots
> and lots of error rules along with adhoc stuff to track the context.
> -John]


This statement is true of yacc and bison in particular, but not LALR
parsing in general. My PhD thesis is on error repair in LR parsers
(It's pretty recent - I graduate in December). I added code to bison
so that the generated parser would include error repair code - tokens
are inserted/deleted at the point of error to repair the input and
allow parsing to continue. The repair - the string of inserts and
deletes - can be the basis for a reasonable error message. The core of
my thesis was trying to do this efficiently. I tested 59643 Java
programs from novice programmers, all of which the compiler had
rejected because of syntax errors. The best effort resulted in 85
"programs" with errors not able to be repaired. Many of these were not
even close to Java (such as a list of numbers, or a different
programming language, or english text).


My thesis is not available online. Yet.


The repair-code was added to a rather old version of bison (1.28) and
is nowhere near production ready. A re-implementation would be better
- the algorithms are all in the thesis. Repairing syntax errors in a
GLR context (i.e. recent bison versions) is likely to be a bit
trickier, but essentially the same (possibly multiple starting points
for a repair).


Now back to work to put the finishing touches on the thesis....


Cheers,
Carl.


Post a followup to this message

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