|Error reporting (for syntactic errors) firstname.lastname@example.org (Roar) (2007-01-08)|
|Re: Error reporting (for syntactic errors) email@example.com (Roar) (2007-01-09)|
|Re: Error reporting (for syntactic errors) firstname.lastname@example.org (Russ Cox) (2007-01-09)|
|Date:||8 Jan 2007 23:35:04 -0500|
|Posted-Date:||08 Jan 2007 23:35:04 EST|
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
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.
Return to the
Search the comp.compilers archives again.