Understanding match context on errors

[Ryan Mohr]

First off awesome job on this library.  It only took me a few minutes to convert my parslet grammar over and it worked perfectly.

I'm using the library to generate autocomplete prompts for a custom language by parsing the error messages.  In most cases I can just look at what was expected by the parser and strip out each expectation as its own prompt.  Sometimes rules don't map over one-to-one though, and there are times where the prompt associated with a rule is determined by what preceded it. 

The current error message gives something like the following: "I expected A, B, or C but ___ found" 

Is it possible to determine something more along these lines?  "Given that I'm in the process of matching X, Y, and Z, I expected A, B, or C but ___ found" 

[Ryan Mohr]

Along similar lines, what about determining what might be expected next after a successful parse?

[Guilherme Vieira]

I think that would be quite useful too, even for humans to understand the source of errors. That shouldn't be hard to implement, also.

Maybe somebody could work on a patch for this?

--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira

[David Majda]

Hi!

2011/11/3 Ryan Mohr <ryan...@gmail.com>:

I was thinking about more structured approach that would be suitable
for machine processing. I'd like to extend the error object with the
following properties:

* The list of expectations (an array).
* What was found (a string).
* Name of the rule the error was triggered in (a string).

Would that solve your needs?

--
David Majda
Entropy fighter
http://majda.cz/

[Ryan Mohr]

Sounds like a great addition.  Would it be possible to include the full stack of previously matched rules instead of just the current one the error was triggered in?

[christo]

I'm really interested in this too.

Just for clarification, the "full stack of previously matched rules"
that I'm talking about though is not the list of previously
successfully matched rules (which may have ended with failures,
backtracks and then a new branch of successes) but actually the "path"
of successful rule matches that led to the current position. In other
words, no backtracks.

This is useful regardless of whether you handle the current point as
an error.

cool library though :)

Chris.

[Ryan Mohr]

Thanks for clarifying Chris.  That's what I was (vaguely) referring to as well.

[David Majda]

2012/2/1 Ryan Mohr <ryan...@gmail.com>:

> Sounds like a great addition.  Would it be possible to include the full
> stack of previously matched rules instead of just the current one the error
> was triggered in?

I am somewhat reluctant to adding this because this information would
have to be computed and maintained dynamically, slowing down the whole
parser even when no error occurs. In contrast, name of the rule the
error was triggered in (= last item on the stack) can be computed
statically.

[Ryan Mohr]

Why not just make it optional?

[David Majda]

2012/2/6 Ryan Mohr <ryan...@gmail.com>:

> Why not just make it optional?

There would need to be more demand for this feature to warrant an option.

I suggest to create an issue on GitHub if you still care about this.
Demand can be estimated easily there by the number of comments.

[Roded Bahat]

I'd like to chime in my enthusiasm regarding this issue.A debug option perhaps? 

Thanks for the great work.

[josh.r...@gmail.com]

So how different is this to the issue here? https://github.com/dmajda/pegjs/issues/9

[David Majda]

2012/12/26 <josh.r...@gmail.com>:

> So how different is this to the issue here? https://github.com/dmajda/pegjs/issues/9

This thread is about getting a path to the currently parsed rule,
while the linked issue is about getting a complete trace of the
parsing process.

[humbe...@gmail.com]

Hi David I agree with Roded, be nice to have an error stack and leave all the analysis concluded. Currently working on my thesis and I'm looking for some way that the analysis does not stop at the first failure