Bug with backtracking and generate? about parsy HOT 4 CLOSED

If this is a limitation of parsy due to its flexibility, documenting that it cannot represent this class of languages (or can't express them in this way, rather) somewhere like https://parsy.readthedocs.io/en/latest/tutorial.html#alternatives-and-backtracking would be helpful.

from parsy.

Eh, I guess it is covered, just in a way that's a bit difficult to reason about. Would there be any way to emulate the sort of backtracking required to handle that case within parsy? In a real scenario, the b parser might be significantly more complicated.

from parsy.

So the | operator (and alt combinator which does the same) is the only built-in way to do backtracking in parsy, and it tries the second option only if the first fails, as documented. I could make this fact a bit clearer.

I don't think there would be an easy way to make parsy do backtracking by default over everything, and for the example you give, it seems impossible in fact: for it to succeed, we would somehow have to instruct the regex engine (i.e. Python's normal regex library) to not consume the za part, or to yield every possible match from the .* instead of the default greedy one, which I don't even think is possible.

Even if we could achieve this, it would drastically change performance characteristics, including the possibility of catastrophic backtracking. So there isn't likely to be a change here.

from parsy.

Alright, that makes sense.

I'm going to close the issue, since the only thing to do would be doc improvements. Thanks for your work on Parsy!

from parsy.