-
Notifications
You must be signed in to change notification settings - Fork 3
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
Multiple repeat operators #37
Comments
Hmm, I think you're right, if we only relax the check for an outer
* You might not see the infinite loop in pe because the packrat parser has a simple guard for loops that do not advance the position, and, secondly, optimized grammars might turn the pattern into a single regex which does not have the infinite loop. ** The re module gives an error for In spite of protections against it, there are some ways to induce the infinite loop. For instance, if you use a capture ( import pe
pe.match('(~"a"*)*', "b", parser="machine") # DANGER: infinite loop I'm prepared to allow
For the "redundant" cases above, it should be safe to allow them, perhaps with a (Aside: while investigating this issue, I came across another bug. See #38) |
I think it would be good to always error on immediate chaining of those operators as in e.g. The fact that some of this chaining is redundant and can be rewritten with only a single operator should be an implementation detail of
which can then be used as e.g.
Furthermore, I would like to point out that e.g.
is not equal to
nor to
this is due to auto-ignoring (of whitespace). |
These are currently blocked at the syntax level (aside: maybe we need a new error class like
One part of pe's design is that non-terminals are not inherently different from inline forms. That is, the
This design is what enables pe to reason about when to optimize patterns. Semantic changes, such as using a Thus, if we allow
Then we must also allow
This is also why the capture in
Apologies if I misunderstood, but I want to be able to detect these things at compile time, not parse time. So I don't want to care if, at parse time,
Yes, I did not bring up auto-ignore in my reply above because I wanted to keep the conversation focused, but I agree that we would need to consider its effects in the multiple repeat operator issue. It's a relatively new feature of pe and I'm still not as certain about its ramifications. |
Indeed that is what I meant. If the formal specification of the rule allows it to potentially match an empty string, don't allow repetition operators on it. |
The following snippet
produces the error
upon compiling it.
It seems like pe thinks that the
?
and the+
operator follow each other immediately and ignores the rule indirection. However, I think a grammar like the above seems perfectly normal.Therefore, this seems like a bug to me.
The text was updated successfully, but these errors were encountered: