http://qs321.pair.com?node_id=812946


in reply to Re^4: Regex fun
in thread Regex fun

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.

Replies are listed 'Best First'.
Re^6: Regex fun
by JavaFan (Canon) on Dec 16, 2009 at 09:00 UTC
    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.