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

blog/nom-error-recovery/ #3

Open
utterances-bot opened this issue Jul 16, 2021 · 11 comments
Open

blog/nom-error-recovery/ #3

utterances-bot opened this issue Jul 16, 2021 · 11 comments

Comments

@utterances-bot
Copy link

Error recovery with parser combinators (using nom) - Eyal Kalderon

If you listen to a UNIX shell, can you hear the C?

https://eyalkalderon.com/blog/nom-error-recovery/

Copy link

arjtala commented Jul 16, 2021

Thanks for the write-up. I think there may be some breaking changes with nom 6, namely:

nom::Err::Error and nom::Err::Failure no longer take tuples but the nom::error:Error struct

nom::Err::Failure((error_remainder, error_kind))

expected struct nom::error::Error, found tuple

Copy link
Owner

Yes, in nom 6, the inner tuple is replaced with the nom::error::Error<I> struct instead, which provides the same fields.

@arjtala
Copy link

arjtala commented Jul 16, 2021

I only realized this after writing my comment and have managed to fix the breaking changes

@ebkalderon
Copy link
Owner

No worries! This post and associated example code were both originally drafted with nom 5.0 in mind, so some breakage was unfortunately inevitable. Glad you managed to upgrade it to the newer version.

Copy link

This was quit helpful! I am making my own person use combinator lib and will "try" to use this information to implment it in mine. Language Dev is EXTREMLY FUN! lol. Keep up the blogs!

Copy link

For other folks who come along: the other big change between when this was published and now is that Nom updated to use FnMut rather than Fn so in the definition of expect you’ll need to update the bounds accordingly.


Thanks for this post—really, really helpful for me! Did you make any progress on implementing the rest of the recovery strategies?

Copy link

epage commented Dec 27, 2022

Could you point me to any of the combinators you have written for this? I'd love to start generalizing all of this for wider nom use.

@ebkalderon
Copy link
Owner

@chriskrycho @epage Glad you found this post helpful! Unfortunately, I haven't gotten around to translating more combinators from this paper beyond those already demonstrated in the post. Still, this is definitely on my radar for this coming year! I've since found an open-access copy of the paper beyond the ACM DL available here: https://arxiv.org/pdf/1806.11150.pdf

@epage
Copy link

epage commented Dec 30, 2022

Thanks for that link!

One of the challenges with error recovery will be performance (at least for toml_edit) I've tried three different Located<I> traits and the fastest one made parsing take 30% longer without even requesting any input spans (see winnow-rs/winnow#61 which is against a short-lived research fork). I expect error recovery will similarly have negative performance impact by just existing.

Something I want to look into is switching parsing from FnMut(I) -> IResullt<I, O> to FnMut(&mut I) -> IResult<O> to see if that can reduce the cost of adding state to the parser. I'm just sad as the original FnMut is more elegant.

Copy link

chiichen commented Nov 8, 2023

Very good article, I would like to ask if it can be translated and reprinted on my personal blog, with the source of the monogram

Copy link

epage commented Feb 2, 2024

As an update, I've added a prototupe of error recovery support to winnow, my alternative to nom: winnow-rs/winnow#388

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

No branches or pull requests

7 participants