
Generating Good Syntax Errors - fogus
http://research.swtch.com/2010/01/generating-good-syntax-errors.html
======
Periodic
I thought most of these errors could be handled with the error construct in
Bison? I suppose most errors tend to get written as "Unexpected TOKEN,
expected OTHER_TOKEN."

If you're willing to complicate your grammar a bit you can add productions for
a lot of the erroneous situations which could arrise with nice error messages,
such as:

for_init := ... | var error { error("var not allowed in for initializer."); }

My syntax is a bit off, but can't all syntax errors be expressed with the CFG
and be given errors as semantic actions?

------
blahedo
I'm teaching CS1 right now, and am daily reminded about just how utterly
_awful_ compiler messages are if you don't already understand how compilers
work. Not only is this a good idea in general, it also adapts nicely to the
educational case: the likely use-case to trigger a particular parser error
state might be different for a beginner, and thus require a different error
message, but it sounds like it would be easy to swap out one
(state,nexttok)->errmsg mapping for another.

------
mahmud
The little gem in the middle is fantastic: using a data set of newbie errors
to train the parser with friendly error messages. This step is done after the
parser is generated, but _before_ it's distributed.

