Ellaborate error messages

[Ejdamm]

tl;dr Error messages from parsing would need some elaboration about where the error occurred.

I'm parsing from command line with a grammar file and an input string from file and it works just as I want when there are no errors. However if there is a syntax error in the input file Bullwinkle will tell me there is an error but not where it is located. Only "ERROR parsing input". It's not even clear if the error is in the input file or in the grammar. If I would have a very large input file Bullwinkle would become unusable as a parser. Maybe the error message could tell which line and column the error was detected.

The project I'm working with needs parsing from a BNF grammar but no compilation is needed. That is why this library is what I need and the user guide is very well documented. Thank you!

[sylvainhalle]

Hi! Thanks for your interest in Bullwinkle.

There are two levels of error that can happen:

• Errors when parsing a file that defines a grammar in BNF. This part could indeed be improved to indicate what line causes the error.
• Errors when parsing a string with respect to a grammar. That part is harder, as the parser uses recursive descent to parse a string. An error occurs when all parsing possibilities have been exhausted, meaning that the recursive procedure returns from the root node with null. In this context, it is hard to pinpoint what part of the string was actually wrong. Any ideas?

[sylvainhalle]

Related: https://stackoverflow.com/questions/30910842/error-reporting-in-a-recursive-descent-parser

[Ejdamm]

I did a quick and dirty test of the consume method described in the SO thread.
It is uploaded here https://github.com/Ejdamm/Bullwinkle-fork/tree/consume_test
It works for some cases when testing it on the example grammar in the root folder (SELECT foo FROM bar). Too make the testing easier I narrowed down the grammar to only accept "foo" as tablename and "bar" as criterion.

All these reported where the error was just fine:
sSELECT foo FROM bar
SELECT sfoo FROM bar
SELECT foo sFROM bar
SELECT foo FROM bars

These did not work well:
SELECT foo FROM sbar
SELECT foo FROMs bar

I think it has to do something with not parsing one token per recursive call. It parses both foo and FROM in the same call if I remember correctly. I just wanted to share my progress before I disappear again ;) I probably have to put some effort to refactor the parsing method to get a better understanding what is happening, but I don't have the time for that right now.

[sylvainhalle]

Interesting! I'll flag this thread as an enhancement for the next release