blog/nom-error-recovery/

[utterances-bot]

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/

[arjtala]

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 structnom::error::Error, found tuple

[ebkalderon]

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

[arjtala]

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

[ebkalderon]

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.

[cowboy8625]

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!

[chriskrycho]

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?

[epage]

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]

@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]

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 https://github.com/epage/nom-experimental/pull/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.

[Chiichen]

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

[epage]

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