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
