in reply to Re^3: (??{ code }) versus (?PARNO) for recursive regular expressions
in thread (??{ code }) versus (?PARNO) for recursive regular expressions

Now I'm definitely going down the old memory train. When I first used the (??{ code }) feature, we had to declare our globals using vars.

use vars qw($x_re);

$x = qr/... (??{ $x }) .../

[download]

This of course worked, but we were quite excited when they released our with perl561delta. Near that point in time, the following did work as desired without throwing errors:

use strict;

our $x = qr/... (??{ $x }) .../

[download]

The thing as, as I understand the documentation of perlre, it should be allowed

This is a "postponed" regular subexpression. The code is evaluated at run time, at the moment this subexpression may match.

The whole point of being able to do a recursive regular expression is that you can include the qr// regex that you're currently defining. However, given the choices you listed above, I'd probably go with the following even if it does feel messy

our $x = qr/... (??{ our $x }) .../

[download]

Anyway, putting all that aside, I'd still like to get back to my primary question. Is this a feature that I should keep in my toolkit, or should I just drop it in favor of (?PARNO)? I can't think of any situation currently where I'd need the former over the latter, but I would like to know if y'all would consider still using it or not.

Replies are listed 'Best First'.
Re^5: (??{ code }) versus (?PARNO) for recursive regular expressions
by ikegami (Patriarch) on Mar 25, 2011 at 23:46 UTC

    The thing as, as I understand the documentation of perlre, [use strict; our $x = qr/... (??{ $x }) .../ ] should be allowed

    You're using a variable ($x) you haven't declared yet. It's a strict error just like 

    $ perl -e'use strict; our $x = $x;'

$

    [download]

    huh... what? I guess I was wrong. our declarations take effect immediately. I don't see why «our $x = $x;» and «our $x = qr/(??{ $x })/;» can behave differently. It would seem there's a bug here.

[reply]
[d/l]
[select]

      Thank you for the sanity check. I ran your above statements on strawberry perl v5.12.1

      > perl -e"use strict; our $x = $x;"
> perl -e"use strict; our $x = qr/(??{ $x })/;"
Variable "$x" is not imported at (re_eval 1) line 2.
Global symbol "$x" requires explicit package name at (re_eval 1) line 
+2.
Compilation failed in regexp at -e line 1.
> perl -e"use strict; my $x = qr/(??{ $x })/;"
Global symbol "$x" requires explicit package name at (re_eval 1) line 
+2.
Compilation failed in regexp at -e line 1.

      [download]

      And on perl v5.10.0 built for i686-linux

      $ perl -e'use strict; our $x=$x;'
$ perl -e'use strict; our $x=qr/(??{ $x })/;'
Variable "$x" is not imported at (re_eval 1) line 2.
Global symbol "$x" requires explicit package name at (re_eval 1) line 
+2.
Compilation failed in regexp at -e line 1.
$ perl -e'use strict; my $x = qr/(??{ $x })/;'
Global symbol "$x" requires explicit package name at (re_eval 1) line 
+2.
Compilation failed in regexp at -e line 1.

      [download]

      However, done on perl v5.8.0 built for i386-linux-thread-multi, I get no strictures errors and the original parsing code works as desired.:

      $ perl -e'use strict; our $x = $x'
$ perl -e'use strict; our $x = qr/(??{ $x })/;'
$ perl -e'use strict; my $x = qr/(??{ $x })/;'

      [download]

      So this change to the way (??{ code }) was validated for strictures changed at least after v5.8.0. Maybe this was done when (?PARNO) was introduced in v5.10.0. I guess that's one way to encourage people to move to a new feature. Gotta say it's still annoying though.

      Update: Added data on my declarations using (??{ code }) per ikegami's request.

[reply]
[d/l]
[select]
        Try 
        perl -e'use strict; my $x = qr/(??{ $x })/;'

        [download]
        on 5.8.0 for me please
[reply]
[d/l]

In Section Seekers of Perl Wisdom