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] |
