-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
regexp: add possessive quantifiers #7713
Labels
Milestone
Comments
Note that this feature was requested on the ML by someone who was showed an easy solution to the case he presented. He only said his case is "more complex" but never shown a particular "complex" case which current regexp package cannot solve. As the guy even seemingly never accepted the fact that package regexp does not backtrace, I tend to think that his understanding of REs is not sound and his non presented actual use case probably _is_ covered by the current regexp package. Also I think the implementation would be problematic - excluding certain states from a state set lazily is IMO not very compatible with what (executing) a NFA is, and it sounds like backtracking. |
Comment 2 by amit.lavon@mail.huji.ac.il: Had the commenter above read the discussion thoroughly, he would have understood that the requester had never asked for a solution for the simple example he presented. He only asked why there are no possessive quantifiers in go - which no one answered. Yet people who don't understand what possessive quantifiers are jumped up and tried to prove the requester wrong without reading the question, as did the guy above, making arrogant comments about the requester's background. Please relate to this feature request as "it would be great to have ..." instead of "find me a solution for ...", same way we can parse arguments without the flag package but it still exists. So possessive quantifiers can be very helpful, even if you specifically can't think of a uses for them. Because there are. |
Had the commenter above read the discussion thoroughly, he would have noted that he has been told 3 or 4, maybe even 5 times that package regexp does not backtrack. Yet he insisted that he "proved" the backtracking. As that is absurd, any conclusions derived from the false fact are invalid. Truth is not arrogant. You are however right that you've never asked for a solution to a problem you have. And that's the point: You might in that case have got a satisfactory solution. Who knows... Conclusion: You're asking for a feature which you claim, without any proof presented, solves a problem which you didn't even show to anyone. Notice that I'm not saying the feature request should be accepted or rejected. I'm just pointing out that there's no evidence the change provides anything worth the work needed to possibly implement it. Also, it seems to be the first regexp feature request for this very functionality in the sixth year Go is public. Additionally, I still have a feeling the change may be equal to the introduction of backtracking (far from sure I'm). """" possessive quantifiers can be very helpful, even if you specifically can't think of a uses for them. Because there are. """" The burden of proof is obviously at your side. Show a concrete problem which it solves and where the current regexp doesn't help and you can easily win your case by rational argument. Hand waving, seen so far, is going to convince few, if anyone. If you're still interested in this kind of conversation, let's please return it to the ML. This place is not appropriate. |
rsc wrote in a comment in CL 67590 that
So I think this can be closed. Closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: