This message probably won't thread well. I wasn't a member of the
mailing list when Robert's original was sent. Sorry.
Robert:
Error messages in parsers are about as much art as science. Figuring
out a good interface to allow PRD users to generate good error
messages borders on black magic.
> the unmodified input parses nicely, and if I uncomment any of the two
> syntax errors, it correctly rejects the input. excellent. but the error
> reporting is slightly less than ideal: the error case 1 will set off the
> <error> directive of the 'fact' rule (good), but *also* the <error>
> directive of the 'code' rule, which is a bit odd.
Believe it or not, the double error messages is considered a feature.
PRD keeps a stack of error messages that it accumulates as it winds
its way back up the call stack used for parsing. After all, it is
possible that some rule "above" fact (meaning that it called "fact" or
call a rule that called "fact" etc), is okay with the idea that "fact"
failed and has something else to try.
<error?> (and friends) are not "die". They do not force the parser to
stop dead in its track. All they do is say to give up on the current
rule - and record that fact - either through an autogenerated message
or using a message the grammar writer supplies.
If you truly want to stop dead, one option is to actually die:
fact : <rulevar: $sawfact>
| 'fact' {$sawfact = 1} <commit> identifier ';'
| <uncommit> { die "Something is rotten in state of Denmark at
line $thisline\n" if $sawfact }
Of course, the surrounding script better be ready for the exception...
I hope this was helpful.
Mark.
If you are bound to
