Better error reporting

[ieure]

One of the things I've found challenging with moderately complex parsers is getting a clear handle on their failure modes. There are a number of things about Parsatron that make debugging challenging.

1. Errors include the line and position of the input, but doesn't tell you about the parser in error. When dealing with a complex parser which calls other complex parsers, it is hard to determine which one is causing the error.

2. The way (either …) merges errors makes it hard to even see what the cause of the problem was. For example, this simple parser:

   (run (choice (char \A) (char \B) (char \C)) "abcdef")

   Produces this awful error:

   java.lang.RuntimeException: Unexpected token 'a', Unexpected token 'a', Unexpected token 'a', Error at line: 1 column: 1
   

   It includes the message from every parser which failed, even though the messages are identical, which obscures what is actually going on. At the very least, it should filter the messages so they are distinct, but I think the behavior is questionable, period.

3. It would be terrific if the line of input which parsing failed on was printed on failure. It can be hard to orient yourself without this context. I know Parsatron can parse structured data, but the assumption that lines of text are the source is already baked in (position assumes parsing text from a file #24). May as well make the assumption worthwhile, I think.

[youngnh]

All of your points are well-taken. I don't disagree with any of them, but I'm not sure I can devote much time to fixing them until after the new year. At that point, I think the whole project needs a roadmap to plan out some much-needed active development.

Thanks for using the library and providing points for improving it.

[bwo]

AIUI, edward kmett's trifecta library (https://github.com/ekmett/trifecta/) doesn't attempt to show informative error messages like that unless you explicitly give your parser a name using the <?> combinator, which isn't necessarily the most user-friendly thing for the writer of the parser but might make it a lot easier for parser consumers. (I'm not at all sure I do understand it, though.)