From: Hugo <[EMAIL PROTECTED]>
Sent: Tuesday, September 12, 2000 2:54 PM
> 3. The regexp is matched left to right: first the lookbehind, then 'X',
> then '[yz]'.
Thanks for the insight - I was stuck in my bad assumption that the optimized
behavior was the only behavior.
What I am not sure of is
From: Hugo <[EMAIL PROTECTED]>
Sent: Monday, September 11, 2000 11:59 PM
> mike mulligan replied to Peter Heslin:
> : ... it is greedy in the sense of the forward matching "*" or "+"
constructs.
> : [snip]
>
> This is nothing to do with greediness and
n that we do have the += family of assignment
operators, does anyone find anything attractive in the following?
split= /\s+/, $name;
quotemeta= $string;
reverse= @array;
sort= { $a <=> $b } @vals;
- mike mulligan
, before succeeding on the 8th try. If
the "*" was greedier than the look-behind, you would expect 2 look-behind
failures, and success on the 3rd.
This doesn't argue against a variable-length lookbehind as a useful feature,
but it may not be what you were looking for.
- mik
nd
proposed look-behinds working the same. So let me retract what I said above
about matching GHIDEFJKLABCMNO A match would be had with
/GHI.*(?`<=DEF)JKL.*(?`<=ABC)MNO/
mike mulligan
regex engine performance shouldn't be allowed to degrade.
It might be possible to unroll this imagined inner test outside the loop -
in other words, much of the "advance the pointer" code in the regex gets
duplicated, once for going forwards and once for going backwards.
mike mulligan
I've been lurking a few days now, and RFC 72 piqued my interest. I see the
motivation for a backwards-moving regexp engine, but am uncomfortable with
the details.
First worry is the syntax proposed. I cringe when I see the regexp being
expressed such that "(?r)EDCB" matches "BCDE". That and th
