error messages

[rain-1]

it needs to produce useful error messages on a parse failure.

[rain-1]

• http://scg.unibe.ch/archive/masters/Ruef16a.pdf
• http://www.inf.puc-rio.br/~roberto/docs/sblp2013-1.pdf

[rain-1]

https://github.com/rain-1/racket-peg/commit/3fc163a73da72871943193962c6a4fb189a6dd5d adds basic error reporting. Could use improvement.

[rain-1]

Support error annotations. LPeg has this.

[petrolifero]

Basically, based in this papers, there's two approachs : the heuristic longest prefix and the error scheme continuation-based.

The first is simpler, but put bad answer. The second is complex but give better answer. I will create one branch to implement the first. If is suficient to the use case that we actually have, we can use it and dedicated more time to others features of peg, while I read the second with more love, because yet is a lot confusing, there's some structures that I need to test a lot to just understand.

What do you think?

[rain-1]

currently we have (pegvm-update-best-error!) implementing longest match. I find the current error reporting is enough help me fix my parsers so improving error messages would be nice, but not highest priority.

to improve errors we will need to make a collection of parses fails and see the error messages. Then tweak the algorithm to improve it for the failures.

[petrolifero]

what are, in your view, the highest priorities in order of importance?

[rain-1]

Good question!

• I want to make sure it's easy to use. Making the API useful and the documentation clear.
• I want to make sure anybody can contribute to it if they wish to. Github opens contribution up nicely.
• I want to continue working on the semantic actions toolkit.
• More test programs/examples.
• Maybe consider removing ; at end of rule.
• Any other ideas?

[petrolifero]

• "easy to use" is some ... subjective, right? I think that, as the most time of maintainer is invested in bugs, after of course the program go to mature, documentation is the more important thing.

• To make more people want to contribute, I can put efforts in examples and tests.

• I don't know exactly, after more tests maybe, we can do more in the other repository, on semantic actions. To me we can test more 5 or 6 times and integrate here.

• Documentation of pegvm is important too and is not so clear. (see this for my dumb questions . :D)

• I don't think remove ; is important.

I see that we have two forks, one mine and other of a guy that is developer of racket if I understand correctly. Can you see the downloads of peg in the pkg? Maybe is not a lot used, contributed or criticized(in a constructive way) because few people know about it.