Re: RFC 308 (v1) Ban Perl hooks into regexes

In <[email protected]>, Tom Christiansen writes:
:>I consider recursive regexps very useful:
:>
:>     $a = qr{ (?> [^()]+ ) | \( (??{ $a }) \) };
:
:Yes, they're "useful", but darned tricky sometimes, and in
:ways other than simple regex-related stuff.  For example,
:consider what happens if you do
:
:    my $regex = qr{ (?> [^()]+ ) | \( (??{ $regex }) \) };
:
:That doesn't work due to differing scopings on either side
:of the assignment.

Yes, this is a problem. But it bites people in other situations
as well:
  my $fib = sub { $_[0] < 2 ? 1 : &$fib($_[0] - 1) };

I haven't kept up with the non-regexp RFCs, but I hope someone
has suggested an alternative scoping that would permit these
cases to refer to the just-introduced variable. Perhaps we
should special-case qr{} and sub{} - I can't offhand think of
another area that suffers from this, and I don't think these
two areas would suffer from an inability to refer to the same-
-name variable in an outlying scope.

A useful alternative might be a different special case. Plucking
random grammar, perhaps:
  my $regex = qr{ (?> [^()]+ ) | \( ^^ \) }x;

Certainly I think a simple self-reference is likely to be a
common enough use that it would help to avoid the full deferred
eval infrastructure, even when it works properly.

:And clearly a non-regex approach could be more legible for
:recursive parsing.

Like any aspect of programming, if you use it regularly it will
become easier to read. And comments are a wonderful thing.

Hugo