Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^3: Regex fun

by JadeNB (Chaplain)
on Dec 15, 2009 at 20:22 UTC ( #812931=note: print w/replies, xml ) Need Help??


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

But you can, sometimes, use it in the replacement part.
Sure, but you're not supposed to: Warning on \1 Instead of $1.
But in /([0-9]+){$1}/, the first capture is completed before the quantifier. So, that's not the reason.
Sorry, I don't understand—not the reason for what?
It's a restriction that should have been removed after the regexp engine was no longer recursive.
Sorry, I don't understand this, either. Do you mean ‘re-entrant’? (UPDATE: Nope, just my internals-ignorance revealed. Thanks, ikegami!)

Replies are listed 'Best First'.
Re^4: Regex fun
by ikegami (Pope) on Dec 15, 2009 at 20:30 UTC
    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.
Re^4: Regex fun
by JavaFan (Canon) on Dec 15, 2009 at 22:13 UTC
    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.
      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.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://812931]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2020-04-10 10:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The most amusing oxymoron is:
















    Results (49 votes). Check out past polls.

    Notices?