Re^2: Inexplicable uninitialized value when using (?{...}) regexp construct.

I must have been wrong when I said:
I have also tried using $num (and the other variables used within the regexp) as package globals, with our, as well as with use vars, thinking that maybe lexical scoping was causing my pain. In so doing, I declared those variables at the top of the script to give them the broadest possible exposure. Again, no change; the second snippet fails, and the first snippet works great.

I guess I wasn't atomic/careful enough in my testing. In converting to globals I may have broken something else, because you're right; after re-testing, converting to globals makes the script work.

Based on your, and others' comments I dove back into perlre to see if I could find mention that lexicals are quirky when used within (?{...}) constructs. I didn't find any such warning, aside from the familiar "This feature is considered highly experimental", applied to the construct as a whole. Should this be submitted as a documentation patch? Is this topic addressed elsewhere in the POD?

Dave

Comment on Re^2: Inexplicable uninitialized value when using (?{...}) regexp construct.

Replies are listed 'Best First'.
Re^3: Inexplicable uninitialized value when using (?{...}) regexp construct. by BrowserUk (Patriarch) on Sep 29, 2004 at 00:24 UTC
I got bitten by this a few times early on, without necessarially realising that the cause was the closures caused by using lexicals in the code blocks. I just found that using our and/or local meant things worked as I wanted them too. This is one of the few places where the closure behaviour of Perl's lexicals is distinctly not useful. I've never seen any mention of this in the POD, though it has come up here and on p5p a few times. I think a documentation patch is a very good idea, though I have my doubts as to the usefulness of a full explanation of the causes and effects. I think a simple "Don't use lexicals in code assertions!" would probably suffice, be more beneficial and less confusing. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply]
Re^4: Inexplicable uninitialized value when using (?{...}) regexp construct. by davido (Cardinal) on Sep 29, 2004 at 01:15 UTC
Does this sound reasonable? perlre Inside the (?{...}) block, $_ refers to the string the regular express +ion is matching against. You can also use pos() to know what is the c +urrent position of matching withing this string. + Currently, lexical (my) variables within a (?{...}) block can be + problematic, as their use may lead to the unintentional creation of + a lexical closure. For that reason it is usually advisable to + use globals in (?{...}) blocks. The code is properly scoped in the following sense: If the assertion i +s backtracked (compare "Backtracking"), all changes introduced after +localization are undone, so that [download] Dave	[reply] [d/l]
Re^5: Inexplicable uninitialized value when using (?{...}) regexp construct. by BrowserUk (Patriarch) on Sep 29, 2004 at 01:36 UTC
Makes sense to me, but the guys on p5p will have better critique. I think I might make the last bit: `+ use (preferably localised) globals in (?{...}) blocks.` [download] Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply] [d/l]
Re^3: Inexplicable uninitialized value when using (?{...}) regexp construct. by diotalevi (Canon) on Sep 28, 2004 at 22:55 UTC
Lexicals aren't "quirky" here. They are just used like any other closure. You just aren't convincing perl that it should go to the trouble of recompiling your regular expression each time. If you start your regex with something like `(?#@{[rand]})` then you'll have a nicely random part of your regex to get it to recompile each time.	[reply] [d/l]