Re: $? and $! equivalents

On Fri, 14 Sep 2018 18:15:21 -0400 Brandon Allbery wrote: > Magic variables make multiple threads impossible, which is why perl 5 > is stuck with ithreads: what happens if two threads each "run" > something at around the same time? > > In Perl 6, you have a Proc object for each subprocess, and c

Re: $? and $! equivalents

OK, different paradigm, different methods. Thanks. Another couple of entries for the "differences" list? Even a note the thing doesn't exist saves fruitless further searching. On 9/14/18, Brad Gilbert wrote: > On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote: >> >> This

Re: $? and $! equivalents

On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote: > > This is probably going to be a forehead-slapper, but I can't find a > reference in either perlintro.com or http://docs.perl6.org/ > (5to6-perlfunc or top-down) for the equivalents of $? and $! in > P6.What are they? > >

Re: $? and $! equivalents

Magic variables make multiple threads impossible, which is why perl 5 is stuck with ithreads: what happens if two threads each "run" something at around the same time? In Perl 6, you have a Proc object for each subprocess, and can query it for its status and/or result code; for things like sub run

Re: allow .re and .im to be l-values

On 05/19/2012 06:05 AM, Siddhant Saraf wrote: > r: my $x = 4 + 2i; $x.re = 5; > rakudo 45679a: OUTPUT«Cannot assign to a non-container␤ in > block at /tmp/PeeJaa8bWJ:1␤␤» > > I think $x.re (Real part of $x) and $x.im (Imaginary part of $x) > should be allowed to be l-values. > What do you sa

allow .re and .im to be l-values

r: my $x = 4 + 2i; $x.re = 5; rakudo 45679a: OUTPUT«Cannot assign to a non-container␤ in block at /tmp/PeeJaa8bWJ:1␤␤» I think $x.re (Real part of $x) and $x.im (Imaginary part of $x) should be allowed to be l-values. What do you say? Will this affect the performance of Rakudo, Niecza ? Recen

Re: and in S05

On Sat, Jun 21, 2008 at 01:59:28PM -0700, cognominal wrote: : C and being zero width assertions , I think they must : always be called with : a question mark. This is not the case line 394 and 1537. : Perljam suggested that a zero width assertion can be also a capturing : one and that : could exp

Re: &, &&, and backtracking.

On Thu, Sep 06, 2007 at 03:49:42PM -0700, Larry Wall wrote: : On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote: : : I agree. One thought I had was that perhaps non-greedy matching : : could also terminate the token prefix. : : Well, that's more or less arguing it the other way.

Re: &, &&, and backtracking.

On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote: : I agree. One thought I had was that perhaps non-greedy matching : could also terminate the token prefix. Well, that's more or less arguing it the other way. It kind of assumes your fooba-ish arguments are smart enough to test

Re: &, &&, and backtracking.

On Thu, Sep 06, 2007 at 12:37:37PM -0700, Larry Wall wrote: > On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote: > : On a somewhat similar question, what happens with a pattern > : such as > : > : "foobar" ~~ / foo.+? | fooba / > : > : The LHS initially matches "foob", but wi

Re: &, &&, and backtracking.

On Thu, 2007-09-06 at 12:37 -0700, Larry Wall wrote: > Yow. ICATBW. The what now? -'f

Re: &, &&, and backtracking.

On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote: : > Were we using the procedural conjunction: : > : > "foobar" ~~ / <[a..z]>+ && [ ... ] /; : > : > I would guess that the LHS matches as much as it can ("foobar"), then : > the RHS matches "foo" [...and then backtracks the L

Re: &, &&, and backtracking.

On Wed, Sep 05, 2007 at 09:36:24PM -0500, Jonathan Scott Duff wrote: > How do C<&> and C<&&> differ with respect to backtracking? For instance, > > "foobar" ~~ / <[a..z]>+ & [ ... ] /; > > Both sides of the C<&> happen in parallel, so I would guess that they > both match "foo" then stop. Ple

Re: &, &&, and backtracking.

Jonathan Scott Duff wrote: > How do C<&> and C<&&> differ with respect to backtracking? For instance, > > "foobar" ~~ / <[a..z]>+ & [ ... ] /; > > Both sides of the C<&> happen in parallel, so I would guess that they > both match "foo" then stop. Please correct me if that's wrong. As written,

Re: === and array-refs

在 2006/8/18 上午 3:31 時，Ben Morrow 寫到： Just to make sure I've got all this straight: =:= compares names === compares containers eqv compares values =:= evaluates both sides as lvalue -- that's VAR() -- and compare them with ===. === evaluates both sides as rvalue and, for containe

Re: === and array-refs

Quoth [EMAIL PROTECTED] ("Mark J. Reed"): > On 8/17/06, David Green <[EMAIL PROTECTED]> wrote: > > >$a=[1, 2, [EMAIL PROTECTED]; > > >$c=[1, 2, [EMAIL PROTECTED]; > > >$d=[1, 2, [EMAIL PROTECTED]; > > > > > >So $a, $c, and $d may all have the same *value* > > >(or "snapshot", when eval

Re: === and array-refs

On Thu, Aug 17, 2006 at 12:00:17AM -0700, Darren Duncan wrote: > As a lead-in, I should say that Synopsis 3 has a good and complete > explanation of these matters and has had it for several weeks, in my > opinion. > > Since you are wanting to compare two mutable Array, just use the eqv > operat

Re: === and array-refs

David Green wrote: No, look at the example I've been using. Two arrays (1, 2, [EMAIL PROTECTED]) and (1, 2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents. "eqv" only tells me whether they have the same value (when @x and @y are evaluated). That's a different question --

Re: === and array-refs

On 8/17/06, David Green <[EMAIL PROTECTED]> wrote: >$a=[1, 2, [EMAIL PROTECTED]; >$c=[1, 2, [EMAIL PROTECTED]; >$d=[1, 2, [EMAIL PROTECTED]; > >So $a, $c, and $d may all have the same *value* >(or "snapshot", when evaluated all the way down >through nesting and references), i.e. they

Re: === and array-refs

On Thu, Aug 17, 2006 at 12:18:55PM -0600, David Green wrote: : So perhaps what I'm looking for is more syntactic : sugar for easily traversing nested data : structures in different ways. Quoth S03: If that's not enough flexibility, there is also an C function that can be passed addition

Re: === and array-refs

On 8/16/06, David Green wrote: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; $a =:= $c; #false, different variables $a === $c; #true, same elements make up $a and $c $a eqv $c; #true, same elements therefore

Re: === and array-refs

On 8/17/06, Darren Duncan wrote: At 11:16 PM -0600 8/16/06, David Green wrote: I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to [1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case (regardless of Seq vs. Array -- I didn't t

Re: === and array-refs

On 8/17/06, Darren Duncan <[EMAIL PROTECTED]> wrote: Generally speaking, the direct use of === is more for specialized purposes, somewhat like the direct use of =:= is. If one can't tell the difference between === and eqv, they most likely want snapshot semantics anyway, and so might as well for

Re: === and array-refs

At 11:16 PM -0600 8/16/06, David Green wrote: On 8/15/06, Darren Duncan wrote: At 2:51 PM -0600 8/15/06, David Green wrote: [...] You are right, but we have both Seq and Array types, so depending which one you use, you want either the === or eqv operators to do what you want. There is no rea

Re: === and array-refs

On 8/16/06, David Green wrote: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; $a =:= $c; #false, different variables $a === $c; #true, same elements make up $a and $c $a eqv $c; #true, same elements therefore

Re: === and array-refs

On 8/15/06, Darren Duncan wrote: At 2:51 PM -0600 8/15/06, David Green wrote: [...] You are right, but we have both Seq and Array types, so depending which one you use, you want either the === or eqv operators to do what you want. There is no reason that === should say 2 Array are equal; we

Re: === and array-refs

Larry Wall schreef: > Dr.Ruud: >> Comparing strings in Perl5, using NFKD: >> >> perl5 -MUnicode::Normalize -we ' >> ($\, $,) = ("\n", "\t") ; >> $x = qq{Henry IV} ; >> $y = qq{Henry \x{2163}} ; >> print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ; >> # $x = NFKD $x ; >> $

Re: === and array-refs

On 8/16/06, Charles Bailey wrote: This is where the "eternal" part starts to confuse me (not picking on your wording, but on the semantics). I'll pick on the wording (wording should always be picked on -- not to be pedantic (OK, I like to be pedantic, but that's not the *only* reason!), but b

Re: === and array-refs

On 8/16/06, Dr.Ruud wrote: I also wondered why a "simple" array (for example containing only value type objects) whould not C<===> its copy. But with .SKID that must be easy to handle. That's what I was wondering that started off this thread. I understand (more or less, I think), why it *does

Re: === and array-refs

On Wed, Aug 16, 2006 at 04:25:13PM +0200, Dr.Ruud wrote: : Comparing strings in Perl5, using NFKD: : : perl5 -MUnicode::Normalize -we ' : ($\, $,) = ("\n", "\t") ; : $x = qq{Henry IV} ; : $y = qq{Henry \x{2163}} ; : print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ; : # $x

Re: === and array-refs

"Markus Laire" schreef: > Dr.Ruud: >> Markus Laire: >>> my $x = 'Just Another'; >>> my $y := $x; >>> $y = 'Perl Hacker'; >>> >>> After this, both $x and $y contain the string "Perl Hacker", since >>> they are really just two different names for the same variable. >>> >> >> So "$x ===

Re: === and array-refs

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: I'll try saying what I meant differently here: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol [or othe

Re: === and array-refs

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: At 11:42 AM +0300 8/16/06, Markus Laire wrote: >On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: >>The difference between === and eqv is that, if you have 2 symbols, $a >>and $b, and $a === $b returns true, then that result is guaranteed to

Re: === and array-refs

On 8/16/06, Dr.Ruud <[EMAIL PROTECTED]> wrote: "Markus Laire" schreef: > my $x = 'Just Another'; > my $y := $x; > $y = 'Perl Hacker'; > > After this, both $x and $y contain the string "Perl Hacker", since > they are really just two different names for the same variable. > So "$x ==

Re: === and array-refs

"Markus Laire" schreef: > my $x = 'Just Another'; > my $y := $x; > $y = 'Perl Hacker'; > > After this, both $x and $y contain the string "Perl Hacker", since > they are really just two different names for the same variable. > So "$x === Sy" stil holds. -- Affijn, Ruud "Gewoon is e

Re: === and array-refs

At 11:42 AM +0300 8/16/06, Markus Laire wrote: On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol afterwar

Re: === and array-refs

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote: Both the === and eqv operators test the actual values of 2 containers, but that their semantics differ in regards to mutable containers. Given an immutable container/type, such as a number or Str or Seq, both will always return true if the val

Re: === and array-refs

It seems to me that there is some confusion being given in this thread and the most recent parts of its predecessor (which can lead to FUD in the wrong hands), so I'll briefly try to clear it up, as I would like to think I understand the issues. At 2:51 PM -0600 8/15/06, David Green wrote: On

Re: $/ and $! should be env (and explanation of env variables)

HaloO, happy new year to Everybody! Luke Palmer wrote: Env variables are implicitly passed up through any number of call frames. Interesting to note that you imagine the call chain to grow upwards where I would say 'implicitly passed down'. Nevertheless I would also think of upwards beeing th

Re: [] and () on rule modifiers

On Fri, Nov 04, 2005 at 01:26:14PM -0600, Patrick R. Michaud wrote: : A05 currently says: : : The first space in : : /[:w foo bar]/ : : matches \s* before "foo". That's usually what you want, : but if it's not what you want, you have a little problem. : Unfortunately y

Re: ~ and + vs. generic eq

HaloO, Yuval Kogman wrote: No, the role installs homogenious targets into the generic binary-MMD comparator which I think is called eqv. Err, why? We already have that with regular MMD semantics. role Num { multi &*infix: ($x:, Num $y) { $x == $y } } What you mean is double dispatc

Re: ~ and + vs. generic eq

On Wed, Sep 21, 2005 at 13:53:20 +0200, TSa wrote: > HaloO Yuval, > > you wrote: > >On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote: > >> role Object does Compare[Object, =:=] > >> role Numdoes Compare[Num, ==] > >> role Strdoes Compare[Str, eq] > >What is the implication of from the

Re: ~ and + vs. generic eq

HaloO Yuval, you wrote: On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote: role Object does Compare[Object, =:=] role Numdoes Compare[Num, ==] role Strdoes Compare[Str, eq] What is the implication of from the perspective of the person using Object, Num and Str? Do they have on

Re: ~ and + vs. generic eq

On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote: > HaloO, > > Damian Conway wrote: > >Just a meta-point...one thing we really do need to be careful of is not > >ending up with 17 different "equality" operators (like certain languages I > >shall refrain from naming). So far we're > >contemplat

Re: ~ and + vs. generic eq

On Wed, Aug 24, 2005 at 16:57:30 +1000, Damian Conway wrote: This is what the operators mean to me: > =:= The right side and the left are the same thing, in the sense that: $x =:= $y; # if this is true $x.mutating_method; # and one side is changed $x =:= $y; # the

Re: ~ and + vs. generic eq

HaloO, Damian Conway wrote: Just a meta-point...one thing we really do need to be careful of is not ending up with 17 different "equality" operators (like certain languages I shall refrain from naming). So far we're contemplating: =:= ~~ == eq eqv equals Do we really

Re: ~ and + vs. generic eq

On Tue, Aug 23, 2005 at 16:32:37 -0700, Larry Wall wrote: > Hmm, well, I don't think >>&op<< is valid syntax, but you did say > "semantics", so I can't criticize that part. :-) What is >><<, btw? Is it &circumfix:{'>>','<<'} (Code &op --> Code); # takes some code, returns a listop or

Re: ~ and + vs. generic eq

Larry wrote: Or we could have a different operator that coerces like == and eq, only via .snap: if [1,2,3] equals [1,2,3] { say "true" } else { say "false" } (Actual name negotiable, of course). The advantage of the latter approach is that you can say @foo >>equals<< @bar and th

Re: ~ and + vs. generic eq

On Wed, Aug 24, 2005 at 12:43:46AM +0300, Yuval Kogman wrote: : On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote: : > On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote: : > : "10" == "10"; # dispatches to Str, due to better match : > : > Nope, that will continue to coerce to n

Re: ~ and + vs. generic eq

On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote: > On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote: > : "10" == "10"; # dispatches to Str, due to better match > > Nope, that will continue to coerce to numeric comparison. The design > team did in fact consider pure "equiv

Re: ~ and + vs. generic eq

On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote: : "10" == "10"; # dispatches to Str, due to better match Nope, that will continue to coerce to numeric comparison. The design team did in fact consider pure "equivalence" MMD dispatch of == in the last meeting, but rejected it in

Re: ~ and + vs. generic eq

On Tue, Aug 23, 2005 at 18:15:07 +0200, Ingo Blechschmidt wrote: > sorry, I've some problems with this proposal: > > == has always meant numeric equality in Perl and I'd like it to stay > that way. For "simple" values like numbers and strings == is numberic, because it's affinity to it. > > "10

Re: ~ and + vs. generic eq

Hi, Yuval Kogman wrote: > I think this is more consistent, and just as useful: > > 10 == 10; # dispatches to num > "10" == 10; # dispatched to Num, by means of coercion (== has some > affinity to it for backwards compatibility) "10" == "10"; # dispatches > to Str, due to better match "10.0" == "1

Re: $ @ and %

On Fri, Nov 26, 2004 at 10:29:52AM +0300, Alexey Trofimenko wrote: : I'm talking about unifying namespaces of arrays, hashes and scalars. I : could swear i've seen some RFC about it.. Yes that's RFC 9, which was discussed and rejected long ago in A2. I just find that I prefer to think of the sig

RE: :, ::, :::, and :::: in P6REs

> > Is that the "soon to be released" E5? > > No, that's the "to be released today" E5. > > ;-) Yy!!

Re: :, ::, :::, and :::: in P6REs

[EMAIL PROTECTED] (Paul Marquess) writes: > Is that the "soon to be released" E5? Sometime today, all being well. -- I often think I'd get better throughput yelling at the modem.

Re: :, ::, :::, and :::: in P6REs

Paul Marquess wrote: > Is that the "soon to be released" E5? No, that's the "to be released today" E5. ;-) Damian

Re: :, ::, :::, and :::: in P6REs

Simon Cozens wrote: > While I'm messing about with REs, is it specified how :any and hypotheticals > interoperate? > >"ab" =~ rx:any / $match := (\w) /; >print $match; > > Can that be undefined behaviour? Please? :) I don't think so. It would probably result in $0 containing an array

RE: :, ::, :::, and :::: in P6REs

> The behaviour is explained quite well in E5 I think. Is that the "soon to be released" E5? Paul

Re: :, ::, :::, and :::: in P6REs

[EMAIL PROTECTED] (Damian Conway) writes: > It's not an exception, but you could certainly *implement* it that way. I would argue that it is in some sense, if not an Official Perl 6 Exception, since it jumps out of several levels of a match. But yeah, I'm probably just looking at this from an imp

Re: :, ::, :::, and :::: in P6REs

> I think I can distinguish :: from ::: - :: fails the current branch point, > whereas ::: fails the entire rule. Correct. > I think I can distinguish between ::: and ; the implementation > is a bit tricky, because ::: fails the current match - easy enough - > whereas has to specify to all upp

Re: -> and .

> I could see something like: > > method operator.( $self: $function ) { > if( $function eq "inc" ) { ++%self.funcount{$_[2]}; } > else { $self.inc( $function ) } > } > > That would count how many times you called each function. Sounds a lot like aspect-oriented programming. If what you want

Re: !< and !>

| | > !< and !> | | How is !< different from >=? ]- the way of Expression or syntax-sugar if u like it :"), and is faster to prononce :") if, if not, unless bigger, smaller, equal less than or equal, bigger than or equal not bigger, not smaller ...etc. Personally I almost always make error wh

Re: !< and !>

"Bryan C. Warnock" wrote: > I'm waiting for someone to say that in tri-state logic, '!<' != '>=' That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b". In SQL this is "$a IS NULL or $a >= $b". - Ken

RE: !< and !>

> -Original Message- > From: Russ Allbery [mailto:[EMAIL PROTECTED]] > Sent: Sunday, September 02, 2001 8:42 AM > To: [EMAIL PROTECTED] > Subject: Re: !< and !> > > > Bart Lateur <[EMAIL PROTECTED]> writes: > > > Why is it ">="

Re: !< and !>

Bart Lateur <[EMAIL PROTECTED]> writes: > Why is it ">=" and not "=>"? Because in English, it's "less than or equal to" not "equal to or less than," I presume. > Simply trying to remember the order of characters might be (a bit of) a > pain. That problem doesn't exist with "!<" and "!>". Every

Re: !< and !>

On 01 Sep 2001 14:40:40 -0700, Russ Allbery wrote: >Sterin, Ilya <[EMAIL PROTECTED]> writes: >>> From: Russ Allbery [mailto:[EMAIL PROTECTED]] > >>> How is !< different from >=? ... >It's the same number of characters. How can it be more convenient? Why is it ">=" and not "=>"? Why "=<" and no

RE: !< and !>

> -Original Message- > From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 01, 2001 5:59 PM > To: Russ Allbery; [EMAIL PROTECTED] > Subject: Re: !< and !> > > > On Saturday 01 September 2001 05:40 pm, Russ Allbery wrote: >

RE: !< and !>

> -Original Message- > From: Andrew Wilson [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 01, 2001 6:06 PM > To: Russ Allbery > Cc: [EMAIL PROTECTED] > Subject: Re: !< and !> > > > On Sat, Sep 01, 2001 at 02:40:40PM -0700, Russ Allbery wrote

Re: !< and !>

On Sat, Sep 01, 2001 at 02:40:40PM -0700, Russ Allbery wrote: > >> How is !< different from >=? > > > It's just more syntax just like foo != bar > > is the same as (foo > bar || foo < bar). Not if you're using Quantum::SuperPositions ;-) > > It might prove convenient to express the expression.

Re: !< and !>

On Saturday 01 September 2001 05:40 pm, Russ Allbery wrote: > Sterin, Ilya <[EMAIL PROTECTED]> writes: > >> From: Russ Allbery [mailto:[EMAIL PROTECTED]] > >> > >> How is !< different from >=? > > > > It's just more syntax just like foo != bar > > is the same as (foo > bar || foo < bar). > > > > I

Re: !< and !>

Sterin, Ilya <[EMAIL PROTECTED]> writes: >> From: Russ Allbery [mailto:[EMAIL PROTECTED]] >> How is !< different from >=? > It's just more syntax just like foo != bar > is the same as (foo > bar || foo < bar). > It might prove convenient to express the expression. It's the same number of char

RE: !< and !>

> -Original Message- > From: Russ Allbery [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 01, 2001 4:03 PM > To: [EMAIL PROTECTED] > Subject: Re: !< and !> > > > raptor <[EMAIL PROTECTED]> writes: > > > I was looking at In

RE: !< and !>

Though it might prove convenient (just more syntax for more than one way to do it) it's equivalent to !< == >= and !> == <= , it might be too confusing, though I myself would think that since != and ne is implemented, !< and !> would definitely make common sense to implement as well. Ilya >

Re: !< and !>

raptor <[EMAIL PROTECTED]> writes: > I was looking at Interbase SELECT syntax and saw these two handy > shortcuts : > = {= | < | > | <= | >= | !< | !> | <> | !=} > !< and !> How is !< different from >=? -- Russ Allbery ([EMAIL PROTECTED])

Re: $& and copying: rfc 158 (was Re: RFC 110 (v3) counting matches)

> > 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. > > I think you should remove the parts of your propsal about making $& be > autolocalized. If you're not planning to revise your RFC, let me know so that I can

Re: $& and copying: rfc 158 (was Re: RFC 110 (v3) counting matches)

> 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

Re: $& and copying: rfc 158 (was Re: RFC 110 (v3) counting matches)

>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

Re: $& and copying: rfc 158 (was Re: RFC 110 (v3) counting matches)

> 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