Special variables

2001-07-13 Thread Mark J. Reed
May I infer from the fact that typeglobs are going away that we will no longer be able to use in our code such lovely global variables as @31415, %42, the filehandle */, etc? I assume that the availability of such was merely an unintended side-effect of the special like-named scalars and the conf

RFC 158 (v3) Regular Expression Special Variables

2000-09-22 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Regular Expression Special Variables =head1 VERSION Maintainer: Uri Guttman <[EMAIL PROTECTED]> Date: 25 Aug 2000 Last Modified: 22 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 158 V

RFC 158 (v2) Regular Expression Special Variables

2000-09-21 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Regular Expression Special Variables =head1 VERSION Maintainer: Uri Guttman <[EMAIL PROTECTED]> Date: 25 Aug 2000 Last Modified: 22 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 158 V

Re: RFC 158 (v1) Regular Expression Special Variables

2000-09-11 Thread Hugo
p pairs are populated with offsets into the target string - immediately after matching, the target string is copied if needed, and the PL_curpm object is updated to refer to the copy - the copy is needed if any of the special variables can be referred to: $`, $&, $', $1, $2, .

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Mark-Jason Dominus
> But maybe the effect of $& is greatly exaggerated or is a relic from > perl4? Has anyone actually benchmarked this recently? Matching with $& enabled is about 40% slower. http://www.plover.com/~mjd/perl/amper.pl

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Mark-Jason Dominus
> >Please correct me if I'm mistaken, but I believe that that's the way > >they are implemented now. A regex match populates the ->startp and > >->endp parts of the regex structure, and the elements of these items > >are byte offsets into the original string. > > I haven't looked at it at all

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread David L. Nicol
Tom Christiansen wrote: > There's also long been talk/thought about making $& and $1 > and friends magic aliases into the original string, which would > save that cost. I was distressed to discover that s///g does not rebuild the old string between matches, but only at the end. It broke my ran

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Uri Guttman
> "MD" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes: >> There's also long been talk/thought about making $& and $1 >> and friends magic aliases into the original string, which would >> save that cost. MD> Please correct me if I'm mistaken, but I believe that that's the way MD>

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Tom Christiansen
>> There's also long been talk/thought about making $& and $1 >> and friends magic aliases into the original string, which would >> save that cost. >Please correct me if I'm mistaken, but I believe that that's the way >they are implemented now. A regex match populates the ->startp and >->endp p

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Mark-Jason Dominus
> There's also long been talk/thought about making $& and $1 > and friends magic aliases into the original string, which would > save that cost. Please correct me if I'm mistaken, but I believe that that's the way they are implemented now. A regex match populates the ->startp and ->endp parts

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Uri Guttman
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> Those weren't the scripts I was thinking about, and it is *NOT* TC> ipso facto true that something which uses $& or $` is poorly TC> written. i wasn't claiming that. a short script using $& would be fine where you don't care ab

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Tom Christiansen
>those early perl3 scripts by lwall floating around in /etc were poorly >written. i am glad they are finally out of the distribution. Those weren't the scripts I was thinking about, and it is *NOT* ipso facto true that something which uses $& or $` is poorly written. --tom

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Uri Guttman
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> $`, $& and $' are useful variables which are never used by any >> experienced Perl hacker since they have well known problems with >> efficiency. TC> That's hardly true. I could show you plenty of code from TC> inexperienc

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Tom Christiansen
>$`, $& and $' are useful variables which are never used by any >experienced Perl hacker since they have well known problems with >efficiency. That's hardly true. I could show you plenty of code from inexperienced Perl hackers like lwall that use them. But the cost in understood. :-) The res

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Eric Roode
>First, $`, $& and $' will be scoped just like $1 and friends. They will >be set by the regex and be only accessible in the current block or a >block which starts with a regex like: > > if ( /foo/ ) { Good idea. $`, $&, and $' will be used immediately 99% of the time. For the rest of the

RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Regular Expression Special Variables =head1 VERSION Maintainer: Uri Guttman <[EMAIL PROTECTED]> Date: 25 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 158 =head1 AB