Home > Archive > Compilers > January 2007 > Error reporting (for syntactic errors)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Error reporting (for syntactic errors)
|
|
|
| This may be a quite basic question. I am contemplating writing a
compiler for a language similar to java, though with some innovative
(hah!) features added, etc etc. I started out with regular BNF, but
have eliminated left recursion from the grammar through allowing the
grammar to directly support lists with separators. I use no tools, all
is written from scratch, and so can create new grammar constructs as I
want.
The grammar is supposed to be (mostly) context free, but as the grammar
is implemented directly as java code, each production being a class,
which at the same time is a node in the parse tree, I have the option
of building and looking up in symbol tables as we go. My grammar is not
complete yet, and I have not had time working on it for a month.
The compiler is backtracking in the sense that if a production fails,
the next alternative, if any, is tried, but it does NOT backtrack
within a production.
The issue is about meaningful error reporting. I have invented a
special grammar element call "point-of-no-return" which is interspersed
throughout the grammar, at points when we KNOW we will not allow
backtracking, typically following certain keywords, such as "if".
The idea is that without such constructs, the grammar will simply fail
to match the input, but we will not know where it actually failed, as
it will backtrack to the degree that we end up with no parse tree, and
no curr-pos in the token-stream, other than always the first token.
What's the "official" way of producing good error messages for
syntactic errors, for example when the code contains:
int i=; // init-expression expected
[There isn't any "official" way, just ways that are more or less bad.
-John]
| |
|
| > [There isn't any "official" way, just ways that are more or less bad.
> -John]
Apart from adding productions for common errors, to recognize and
handle them spesifically, the approach of identifying a
point-of-no-return state inside a grammar production seems to work for
the tests I've done so far.
The idea is that deciding that a production has reached a
point-of-no-return, changes the meaning of failure to match required
elements from that of simply aborting the attempt and letting the
calling production decide what to do, to instead reporting an error,
based on what required element (production or token) failed.
| |
| Russ Cox 2007-01-09, 10:08 pm |
| > The compiler is backtracking in the sense that if a production fails,
> the next alternative, if any, is tried, but it does NOT backtrack
> within a production.
This informal description sounds like the same thing a
packrat parser does. You might look at how the various
packrat parser generators handle error reporting:
See for example section 3.2.4 of
http://pdos.csail.mit.edu/~baford/p...esis/thesis.pdf
Russ
|
|
|
|
|