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

Switching my for our works fine for me with identical setup: AS 5.8.4/XP. Though I have AS 510 and there was an earlier version (AS508?) which I saw another problem that the move to 510 fixed. Maybe this is another?

use strict;
use warnings;

while ( <DATA> ) {
    chomp;
    print bin_to_dec($_), "\n";
}

sub bin_to_dec {
    my $bits = shift;
    our( $power, $magnitude, $num );
    die "$bits is not a pure bit string.\n" if $bits =~ m/[^10]/;
    if (
        $bits =~ m/
                    (?{
                      $power = length($_) - 1;
                      $num = 0;
                    })
                    (?:
                      ([10])
                      (?{
                        $magnitude = 2 ** $power;
                        $^N eq '1' and $num += $magnitude;
                        $power--;
                      })
                    )+
                  /x
    ) {
        return $num;
    } else {
        die "Unable to resolve bits: $bits.\n";
    }
}

__DATA__
00000000
00000011
00000111
11100000
__OUTPUT__
P:\test>junk
0
3
7
224
[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

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

Replies are listed 'Best First'.
Re^2: Inexplicable uninitialized value when using (?{...}) regexp construct. by davido (Cardinal) on Sep 28, 2004 at 20:41 UTC
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	[reply]
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
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]