Re: (??{ code }) versus (?PARNO) for recursive regular expressions

[ikegami]

in reply to (??{ code }) versus (?PARNO) for recursive regular expressions

I can of course work with this limitation, but it's not completely satisfying since it was not necessary before (don't remember version of perl, 5+years ago)

That's not true. Variable declarations have always taken effect in the statement following the one containing the declaration. Perhaps you weren't using lexical ("my") variables (or strict) "5+ years ago".

---

Unrelated, don't use lexicals from outside the pattern inside of (?{ ... }), (??{ ... }) and anything similar.

$ perl -wE'
   sub f {
      my $x = $_[0];
      "" =~ /(??{ say $x; "" })/;
   }
   f("abc");
   f("def");
'
Variable "$x" will not stay shared at (re_eval 1) line 1.
abc
abc

Use a package variable instead.

$ perl -wE'
   sub f {
      local our $x = $_[0];
      "" =~ /(??{ say $x; "" })/;
   }
   f("abc");
   f("def");
'
abc
def

[wind]

My previous time using (??{ code }) 5 years ago, I declared everything using our and of course did use strict. However, that doesn't have any effect on this code now:

our $braces_re = qr/ ... (??{ $braces_re }) ... ) /sx;

Still throws a strictures warning. The only way I've observed being able to get it to work now is by having the variable predeclared, regardless of whether it's done using my or our.

If it helps, it probably was more like 9-10 years ago. Basically very soon after the (??{ code }) feature was introduced.

[ikegami]

Still throws a strictures warning.

Of course. Variable declarations includes our.

These work:

1. no strict;  $x = qr/(??{ $x })/;
2. use strict; our $x = qr/(??{ our $x })/
3. use strict; our $x = qr/(??{ no strict; $x })/
4. use strict; our $x; $x = qr/(??{ $x })/
5. use strict; my $x; $x = qr/(??{ $x })/

I think there was once a bug where some or all pragmas didn't propagate into (??{ }) and the like. If so, the following would have worked because it would have been equivalent to #3 above:

6. use strict; our $x = qr/(??{ $x })/

The earliest I have here is 5.10.1, and it doesn't have this bug.

[wind]

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 }) .../

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 }) .../

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 }) .../

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.