Regarding the last point, the engine was re-engineered for 5.10. It used to use the C stack, so limits were imposed to prevent stack overflows. Now, the stack it uses is on the heap. The implementation moved away from a recursive model as part of the change.
| [reply] |
Sorry, I don't understand—not the reason for what?
Quoting myself where I am quoting you:
the variable that contains the contents of the first capture group is $1, but that's empty until the capture has completed.
You're claiming $1 is "empty" until the the capture has completed. I'm pointing that the in the case of the OP, said first capture has completed.
Do you mean ‘re-entrant’?
No, I don't. The current regexp-engine isn't re-entrant.
| [reply] |
You're claiming $1 is "empty" until the the capture has completed. I'm pointing that the in the case of the OP, said first capture has completed.
I guess that the quotes around ‘empty’ are to point out that, besides the unusual choice of word (in place of ‘undefined’), it's not true—sorry, I'll correct that.
I agree that Hena's second solution doesn't suffer from the problem that I mentioned; but the post particularly asks for a single-regex solution, and I was just mentioning why the obvious substitute, /\+([0-9]+)[$bases]{$1}/, for the non-working regex /\+([0-9]+)[$bases]{\1}/, doesn't work. (Nobody suggested it anyway, so I guess it was pretty unclear what I was talking about.)
No, I don't. The current regexp-engine isn't re-entrant.
Yes, which is why I thought that the final word in “the regexp engine was no longer recursive” might be ‘re-entrant’. :-) (I don't know enough history to know whether it ever was re-entrant, so, for all I knew, the grammar was correct.) I was particularly confused because Perl 5.10 newly allows for recursive regexes, which I confused with the regex engine itself being recursive; but ikegami clarified.
| [reply]
[d/l]
[select] |
The regexp engine has never been re-entrant. It has only mattered since we have /(?{ })/ and /(??{ })/, before that, there was no way to start another match before the first one was finished. So even if it were re-entrant, you couldn't use the fact.
This:
/PAT1 (??{m!PAT2!}) PAT3/
is very likely to do unexpected things due to the regexp engine not being re-entrant. | [reply]
[d/l]
[select] |
