Hi, This is what I did in Grako both for grammar parsing, and for generated parsers:
- Keep a stack of the invoked rules, and print it when the --trace option is used. - Implement a "cut" operator, so errors can be reported as close to the input token that triggered them as possible, even in deeply nested syntactical blocks. I just thought that it is still far from perfect, because "cut" makes the errors be reported against the relevant position in the input, but I still have to go back in the trace to find the failing rule. I think that the solution may be to memorize the rule stack whenever a rule fails to parse. Cheers, On Wed, Nov 20, 2013 at 7:45 PM, Henri Tuhola <henri.tuh...@gmail.com>wrote: > Hello > > How could I extend my simple parser generator such that parsers provide > error reports that show precisely what went wrong? > > I thought it was a nice idea to write myself a parser generator, > specifically tailored for the language I'm going to parse: > https://github.com/cheery/kickrat > > It was quite fun, clean and exciting to create such library but now I've > been prototyping my language for few hours. It was enough for noticing that > when I do an error in describing the grammar it is really hard to figure > out what's wrong with just plain 'syntax error' -message. Overall it would > be nice to get detailed syntax errors for language, even if it's a > prototype. > > _______________________________________________ > PEG mailing list > PEG@lists.csail.mit.edu > https://lists.csail.mit.edu/mailman/listinfo/peg > > -- Juancarlo *Añez*
_______________________________________________ PEG mailing list PEG@lists.csail.mit.edu https://lists.csail.mit.edu/mailman/listinfo/peg
