> (mystery: how
> can filling in $& be a lot slower than filling in $1?)
It isn't. It's the same. $1 might even be more expensive than $&.
It appears that many people don't understand the problem with $&. I
will try to explain.
Maintaining the information required by $1 or $& slows down the
Jonathan Scott Duff wrote:
>
> How about something like this?
>
> $re = qr/(\d\d)-(\d\d)-(\d\d)/g;
> $re->onmatch_callback(push @list, makedate(^0,^1,^2));
> $string =~ $re;
>
It's not bad, but it loses one thing that I was trying to keep from the
SNOBOL model. If you have (a
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
> 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
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
> "MD" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
MD> The $& cost is paid by every regex in the entire program, whether they
MD> used it or not. This is because Perl has no way to tell which regexes
MD> use $& and which do not.
actually it is more like which code refers to $&
> MD> One of Uri's suggestions in RFC 158 was to compute $& only for
> MD> regexes that have a /k modifier. This would solve the $& problem
> MD> because Perl would compute $& only when asked to, and not for
> MD> every other regex in the rest of the program.
>
> the rfc was about makin
>actually it is more like which code refers to $& and which regex that
>caem from. the problem stems from $& being a global and not local like
>$1.
Say what? They scope the same!
sub foo { /./ }
$_ = "stuff";
/.../;
foo();
print $&;
--tom
> in any case, i think we have a fair agreement on rfc 158 and i will
> freeze it if there is no further comments on it.
In light of this:
$& The string matched by the last successful pattern match (not
counting any matches hidden within a BLOCK or eval() enclosed
by the
On Thu 31 Aug, Mark-Jason Dominus wrote:
> Summary report 2831
> RFC 110: counting matches (Richard Proctor)
>
> An extensive side discussion of
>
> $count = () = m/PAT/g;
>
> developed, including an excursion off into context issues. I have
> asked th
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
On Wed, Aug 30, 2000 at 04:07:51PM -0400, mike mulligan wrote:
> Can this be repackaged in such a way that it is a more natural extension of
> the existing regexp language?
>
> The RFC notes that the look-behind construct (?<= pattern) can almost be
> used. Two issues: 1. as currently implement
From: "Peter Heslin" <[EMAIL PROTECTED]>
Sent: Thursday, August 31, 2000 10:51 PM
> I would propose that your version of the syntax might also function in
> the middle of a regexp: /GHI(?`<=DEF)JKL(?`<=^ABC)MNO/ would match the
> start of the alphabet (fixed-length example used for simplicity).
perl6-language-regex
Summary report 2831
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
This topic did not attract much discussion until the very end of the
week. I sent the author a detailed critique, to which he has not
responded.
RFC 93
14 matches
Mail list logo
