in reply to my versus our in nested regex

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)))

[download]

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!

Replies are listed 'Best First'.
Re: Re: my versus our in nested regex
by liz (Monsignor) on Oct 18, 2003 at 17:19 UTC
    ...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.

    [download]

    Liz

[reply]
[d/l]
[select]
Re: Re: my versus our in nested regex
by Anonymous Monk on Oct 18, 2003 at 17:20 UTC

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

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

    [download]

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

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

    [download]

    doesn't complain either.

[reply]
[d/l]
[select]

      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.

      [download]
      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      Hooray!
[reply]
[d/l]

        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. :-)


        ---
        demerphq

          First they ignore you, then they laugh at you, then they fight you, then you win.
          -- Gandhi

[reply]
[d/l]
        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";
}})};

        [download]
        ;)
[reply]
[d/l]

In Section Seekers of Perl Wisdom