Re: my versus our in nested regex

[BrowserUk]

my variables don't come into existance until the end of the statement in which they are declared, which means that when the regex is being compiled, <update> the lexical scalar,<update> $regex doesn't yet exist.

Using our bypasses this problem.

If you want to avoid using a global, then pre-declare the lexical.

use strict;

my $regex;
$regex = qr /(              # Start capture
                \(              # Start with '(',
                (?:             # Followed by
                (?>[^()]+)      # Non-parenthesis
                |(??{ $regex }) # Or a balanced () block
                )*              # zero or more times
                \)              # Close capture
                )/x;            # Ending with ')'

my $text = '(outer(inner(most inner)))';

$text =~ /$regex/gs;

print "$1\n";

__END__
P:\test>junk2
(outer(inner(most inner)))

Updated description in the light of liz's observation below.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!

[liz]

...which means that when the regex is being compiled, $regex doesn't yet exist.

Actually, this is incorrect. $regex does exist but refers to an (undefined) global variable with the same name at that stage. Which the following with strict will reveal:

$ perl -Mstrict -e 'my $foo = $foo'
Global symbol "$foo" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

Liz

[Anonymous Monk]

It is interesting that strict doesn't complain in the following:

use strict;
my $regex = qr/(?{{$regex}})/;

and it isn't just because the parser has seen that variable:

use strict;
my $regex = qr/(?{{$undeclared}})/;

doesn't complain either.

[BrowserUk]

Agreed. Quite why strictness doesn't propogate to regex code blocks is a good question.

You can always enable it yourself:)

P:\test>perl -le"my $re = qr[(??{ use strict; $re })];"
Global symbol "$re" requires explicit package name at (re_eval 1) line
+ 2.
Compilation failed in regexp at -e line 1.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!

[demerphq]

Well, these constructs are experimental. Their behaviour is possibly subject to change in 5.10. Recently Abigail-II posted a doc change patch to p5p to have them no longer marked so, and the 5.10 pumpking rejected it on the grounds that it was one of his intentions to sort out a number of issues related to these constructs and that he couldnt guarantee that their behaviou would be unchanged by doing so. So, use the constructs if you wish, but be aware that you are using beta quality code.

PS, im guessing Hugo will try Real Hard to keep them as close to their current behaviour as possible, but given one of his major objectives of 5.10 is massive improvements to the regex engine its anyones guess what will happen. Hugo, if you're reading this, good luck mate. :-)

[Anonymous Monk]

So it would seem that castaway could trivially implement strict compliant code without all the so-called bother that thus ensues:

#!/usr/bin/perl -w
use strict;

1 =~ m{(?{{
    $foo = 42;
    $bar = 2;
    print $foo * $bar, "\n";
}})};

;)