> There is, but as MJD wrote: "it ain't pretty". Now, semantic checks or
> assertions would be the only reason why I'd expect to be able to execute
> perl code every time a part of a regex is succesfully parsed. Simply
> look at RFC 197: a syntactic extension to regexes just to check if a
> number is within a range! That is absurd, isn't it? Would a simple way
> to include localized tests, *any*¨test, make more sense?
I'm trying to stick to a general philosophy of what's in a reg-ex, and I can
almost justify assertions since as you say, \d, ^, $, (?=), etc are these
very sort of things. I've been avoiding most of this discussion because
it's been so odd, I can't believe they'll ultimately get accepted. Given
the argument that it's unlikely that (?{code}) has been implemented in
production, I can almost see changing it's symantics. From what I
understand, the point would be to run some sort of perl-code and returned
defined / undefined, where undefined forces a back-track.
As you said, we shouldn't encourage full-fledged execution (since core dumps
are common). I can definately see simple optimizations such as (?{$1 op
const}), though other interesting things such as (?{exists $keywords{ $1 }})
might proliferate. That would expand to the general purpose (?{
isKeyword( $1 ) }), which then allows function calls within the reg-ex,
which is just asking for trouble.
One restriction might be to disallow various op-codes within the reg-ex
assertion. Namely user-function calls, reg-ex's, and most OS or IO
operations.
A very common thing could be an optimal /(?>\d+)(?{MIN < $1 && $1 > MAX})/,
where MIN and MAX are constants.
-Michael
