Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reintroduce error recovery from pb1 #42

Open
sirthias opened this issue Dec 20, 2013 · 9 comments
Open

Reintroduce error recovery from pb1 #42

sirthias opened this issue Dec 20, 2013 · 9 comments
Labels
Milestone

Comments

@sirthias
Copy link
Owner

Can be implemented largely by simply wrapping a parser and using a special ParserInput, which allows for insertion and removal of virtual characters in the same way as the MutableInputBuffer from pb1.

The techniques used for recovery in pb1 should still work much the same as before.

@edko99
Copy link

edko99 commented Feb 20, 2015

I am using parboiled2 to build a parser for a small language, and I really like its speed and flexibility. Having error recovery would really help in building a user-friendly text editor for my language. If this feature will not be built, is there any good blog post that explains in detail the techniques used by parboiled1?

@machaval
Copy link

machaval commented Mar 6, 2015

It will really help us to start building tooling around a language be are creating.

@PoloShock
Copy link

I'm currently developing an IDE-like environment with syntax error hints for my users. For now I use parboiled1 but it is very slow for some inputs so I'm considering switching to parboiled2. It would be no-brainer if it had error recovery as the parboiled1 has.

@ppopoff
Copy link

ppopoff commented Nov 16, 2015

+1 for this feature

@JuPfu
Copy link

JuPfu commented Nov 16, 2015

Would be great to have this feature in parboiled2!

@ozgunduz
Copy link

+1 for this feature

@magnus-madsen
Copy link

I know I am a bit late, but could someone expand a bit one what would be needed to implement this?

I see

https://github.com/sirthias/parboiled/blob/master/parboiled-core/src/main/java/org/parboiled/buffers/MutableInputBuffer.java

How much implementation effort would approximately be required and would an outsider be able to do this? :)

@sirthias
Copy link
Owner Author

sirthias commented May 25, 2021

The ParserInput, which roughly corresponds to the input buffers of PB1, are not where the meat of the recovery logic lives.
PB2 would need an equivalent of the RecoveringParseRunner from PB1:
https://github.com/sirthias/parboiled/blob/master/parboiled-core/src/main/java/org/parboiled/parserunners/RecoveringParseRunner.java

Essentially, this ParseRunner implements another layer on the outside, around the actual parser logic, that "watches" how a parser eats through an input. If the parsing run succeeds, all is well. If it doesn't the RecoveringParseRunner "changes" the input somewhat an re-runs the parser, potentially many times. This way it can overcome, one by one, all errors and make the parser succeed eventually.
Even though this process can be much slower that a "normal" parsing run this delay usually doesn't matter at all because error recovery usually only needs to be fast enough in human timescales, which is usually not that hard.

So, error recovery for PB2 should be implementable by adding sth like the MutableInputBuffer as another ParserInput and sth on the outside, wrapping the actual parser (an equivalent to the RecoveringParseRunner from PB1).

Note however: PB2 is essentially EOL, because its macro core cannot be easily ported to Scala 3 and would have to be completely rewritten. AFAICS I won't have the capacity or the drive to do this myself.
Also, the parsing landscape in the Scala ecosystem has changed a lot since "the parboileds" were written (2009 - 2014).
We now have things like fast-parse and cats-parse.

So, if you want to implement error recovery for a Scala parsing framework, I'd look into doing it for one of these newer libraries rather than parboiled2.

@ppopoff
Copy link

ppopoff commented May 25, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants