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

Implement basic cut operator #375

Closed
wants to merge 1 commit into from
Closed

Conversation

DasLixou
Copy link

This implements the ~> cut operator, which after it gets passed, doesn't check for the other rules in choices once failed.

A problem currently is that it's just a bool in the ErrorState and when I understood the architecture correct, something like this:

rule outer()
  = "a" ~> a_inner() { }
  / "b" ~> b_inner() { }

rule a_inner()
  = "another" / "choice" { }

rule b_inner()
  = "where" / "the cut from above" / "wont apply to" { }

will work, but this won't because it uses the same ErrorState

rule outer()
  = "a" ~> ("another" / "choice") { }
  / "b" ~> ("where" / "the cut from earlier" / "will still apply to") { }

Also, is there any discord/zulip etc. where one can ask questions?

@kevinmehall
Copy link
Owner

The ErrorState is shared across all rules when parsing an input string, so this approach doesn't seem right. Once you hit a CutExpr anywhere and set the is_cut flag, the ordered choice operator stops working for the rest of the parse call, whether you're inside or outside of the level of the cut. Both of your examples should be equivalent and I think this will break both.

Also, the / operator is not the only point of backtracking in PEG. How does the cut operator interact with repeat operators in other parsers that implement it?

Stepping back, I'd also want to see realistic examples that motivate the benefit of the cut operator vs rearranging the ordered choice to have the most specific first. In the PEG literature, the main reason for a cut operator is that it allows clearing the packrat parser caches, but rust-peg doesn't cache by default.

I don't have a chat channel for this, but do have GitHub discussions enabled for questions and design discussions.

@DasLixou
Copy link
Author

DasLixou commented May 1, 2024

Thanks for the reply.
Yes, I have only implemented it for the choice and repetition etc. would be also a target where this must be introduced. My main motivation for this was to get performance gains but I think I afterall this would only Safe performance when it errors, right?
After all, I find the translation kind of hard to understand/follow and it seems like the code in this pr wont be the right way so I'll close this.

@DasLixou DasLixou closed this May 1, 2024
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

Successfully merging this pull request may close these issues.

2 participants