> As to your contention that "at best" (?r) will defeat many present
> optimizations, can you tell me why this will necessarily be so in the
> new engine?
Let me explain my thinking along these lines. I've made a number of
assumptions, which may not be correct, and certainly aren't obvious.
I
> Simply put, I want variable-length lookbehind.
Why didn't you simply propose that the (?<...) operator be fixed to
support variable-length expressions? Why so much additional machinery?
On Wed, Aug 30, 2000 at 11:54:29PM -0400, Mark-Jason Dominus wrote:
>
> The big thing I find missing from this RFC is compelling examples.
> You are proposing a major change to the regex engine but you only have
> two examples. Both involve only fixed strings and one of them is
> artificial. I
Whenever I seem to have this "search backwards" urge (not very often,
I admit), I without much thought just throw memory at it with
reverse($str) =~ /pat/
Or, if that's not the "search backwards" sense intended, then maybe
I'll throw time at it:
$str =~ /.*pat/
Sometimes I've also don
> I am unemcumbered by any knowledge of the regex engine implementation,
Yeah.
But I do know something about it, and I have already expressed my
informed opinion. Having you come along to say that you don't know
anything about it at all, but that you nevertheless think I am
mistaken, is bizar
From: Mark-Jason Dominus <[EMAIL PROTECTED]>
Sent: Wednesday, August 30, 2000 11:54 PM
> There are two parts to the $& penalty.
> The first part [ of $& penalty is ] maintaining the information for $&.
> Maintaining this information for your prepos() function is going to
> incur an identical cos
The big thing I find missing from this RFC is compelling examples.
You are proposing a major change to the regex engine but you only have
two examples. Both involve only fixed strings and one of them is
artificial. I really think you need to discuss in more detail why
this feature would be usef
