> On 25 Sep 2000 20:14:52 -0000, Perl6 RFC Librarian wrote:
>
> >Remove C<?{ code }>, C<??{ code }> and friends.
>
> I'm putting the finishing touches on an RFC to drop (?{...}) and replace
> it with something far more localized, hence cleaner: assertions, also in
> Perl code. That way,
>
> /(?<!\d)(\d+)(?{$1 < 256})/
>
> would only match integers between 0 and 255.
>
> Communications between Perl code snippets inside a regex would be
> strongly discouraged.
I can't believe that there currently isn't a means of killing a back-track
based on perl-code. Looking through perlre it seems like you're right. I'm
not really crazy about breaking backward compatibilty like this though. It
shouldn't be too hard to find another character sequence to perform your
above job.
Beyond that, there's a growing rift between reg-ex extenders and purifiers.
I assume the functionality you're trying to produce above is to find the
first bare number that is less than 256 (your above would match the 25 in
256).. Easily fixed by inserting (?!\d) between the second and third
aggregates. If you were to be more strict, you could more simply apply
\b(\d+)\b...
In any case, the above is not very intuitive to the casual observers as
might be
while ( /(\d+)/g ) {
if ( $1 < 256 ) {
$answer = $1;
last;
}
}
Likewise, complex matching tokens are the realm of a parser (I'm almost
getting tired of saying that). Please be kind to your local maintainer,
don't proliferate n'th order code complexities such as recursive or
conditional reg-ex's. Yes, I can mandate that my work doesn't use them, but
it doesn't mean that CPAN won't (and I often have to reverse engineer CPAN
modules to figure out why something isn't working).
That said, nobody should touch the various relative reg-ex operators. I
look at reg-ex as a tokenizer, and things like (?>...) which optimizes
reading, and (?<!..), etc are very useful in this realm.
Just my $0.02
-Michael
