Skip Menu |
Report information
Id: 67694
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: fany [at] cpan.org
vparseval [at] gmail.com
Cc:
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: low
Type: library
Perl Version: 5.10.0
Fixed In: (no value)



Subject: List::Util attaching to the wrong $_ when used inside given/when construct
Date: Sun, 19 Jul 2009 08:25:11 -0400
To: perlbug [...] perl.org
From: ethan <vparseval [...] gmail.com>
Download (untitled) / with headers
text/plain 4.1k
This is a bug report for perl from vparseval@gmail.com, generated with the help of perlbug 1.36 running under perl 5.10.0. ----------------------------------------------------------------- [Please enter your report here] Please behold the following: #!/usr/bin/perl -l use feature qw/switch/; use List::Util qw/first/; my $val = 1; given ($val) { # my $_ when (1) { print +(first { $_ == 10 } 10 .. 15) ? 'works inside when' : 'broken inside when'; } } print +(first { $_ == 10 } 10 .. 15) ? 'works outside when' : 'broken outside when'; __END__ broken inside when works outside when Note that when commenting out the lexical declaration of $_, the code behaves as expected. At this point, I am not sure if the problem is in List::Util or the perl core. List::MoreUtil uses does the same thing as List::Util when it comes to assigning to $_ and dispatching the code-reference hence it's suffering from the same malaise. Cheers, Tassilo [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=library severity=low --- Site configuration information for perl 5.10.0: Configured by Debian Project at Sun May 3 21:49:06 UTC 2009. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.18-xen-3.1-1-amd64, archname=x86_64-linux-gnu-thread-multi uname='linux nautilus 2.6.18-xen-3.1-1-amd64 #1 smp fri oct 19 23:35:59 cest 2007 x86_64 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.3.3', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.9.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0 gnulibc_version='2.9' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib' Locally applied patches: --- @INC for perl 5.10.0: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . --- Environment for perl 5.10.0: HOME=/home/ethan LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/ethan/bin:/home/ethan/bin:/usr/local/bin:/usr/bin:/bin:/usr/games PERL_BADLANG (unset) SHELL=/bin/bash
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Tue, 21 Jul 2009 11:54:44 +0200
To: perl5-porters [...] perl.org
From: Bram <p5p [...] perl.wizbit.be>
Show quoted text
> > ----------------------------------------------------------------- > [Please enter your report here] > > Please behold the following:
[code snipped] Show quoted text
> Note that when commenting out the lexical declaration of $_, the code behaves > as expected.
No it doesn't. Or at least not for me. I suggest you check your test case again. This seem to happen because given creates a lexical $_. It also happens when for/foreach is used with a lexical $_: #!/usr/bin/perl -l use strict; use warnings; use feature qw/switch/; sub s1 (&) { my $code = shift; for ("a") { print "\ts1:\t \$_ = " . \$_ . " (value: $_)"; $code->(); } } print "Given/when block:"; my $val = 1; given ($val) { when (1) { print "\twhen-1:\t \$_ = " . \$_ . " (value: $_)"; s1 { print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; }; print "\twhen-2:\t \$_ = " . \$_ . " (value: $_)"; } } print ""; print "For loop"; for (1) { print "\tfor-1:\t \$_ = " . \$_ . " (value: $_)"; s1 { print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; }; print "\tfor-2:\t \$_ = " . \$_ . " (value: $_)"; } print ""; print "For loop with lexical \$_"; for my $_ (1) { print "\tfor-1:\t \$_ = " . \$_ . " (value: $_)"; s1 { print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; }; print "\tfor-2:\t \$_ = " . \$_ . " (value: $_)"; } __END__ $ perl-5.10.0 rt-67694.pl Given/when block: when-1: $_ = SCALAR(0x994f768) (value: 1) s1: $_ = SCALAR(0x994f478) (value: a) block: $_ = SCALAR(0x994f768) (value: 1) when-2: $_ = SCALAR(0x994f768) (value: 1) For loop for-1: $_ = SCALAR(0x994ed08) (value: 1) s1: $_ = SCALAR(0x994f478) (value: a) block: $_ = SCALAR(0x994f478) (value: a) for-2: $_ = SCALAR(0x994ed08) (value: 1) For loop with lexical $_ for-1: $_ = SCALAR(0x994e848) (value: 1) s1: $_ = SCALAR(0x994f478) (value: a) block: $_ = SCALAR(0x994e848) (value: 1) for-2: $_ = SCALAR(0x994e848) (value: 1) Best regards, Bram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Tue, 21 Jul 2009 12:01:52 +0200
To: Bram <p5p [...] perl.wizbit.be>
From: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
Download (untitled) / with headers
text/plain 951b
2009/7/21 Bram <p5p@perl.wizbit.be>: Show quoted text
> This seem to happen because given creates a lexical $_. It also happens when > for/foreach is used with a lexical $_:
Hmm what ? No, given does not create a lexical $_ : from pp_entergiven : if (PL_op->op_targ == 0) { SV ** const defsv_p = &GvSV(PL_defgv); *defsv_p = newSVsv(POPs); SAVECLEARSV(*defsv_p); } else sv_setsv(PAD_SV(PL_op->op_targ), POPs); (rewriting that with the proper macros will be nice) (not sure if there is absolutely no bug there) What happens, at first glance, it that List::Util always uses the global $_. (an "our $_" in the "first" block should solve the pb). We provide UNDERBAR and dUNDERBAR macros to access the current $_, be it lexical or global. However we don't have (yet) an API to localize the current $_ as needed in grep-like functions. I suppose that code from pp_grepstart could be copied in List::Util to solve the bug.
CC: perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Tue, 21 Jul 2009 12:24:26 +0200
To: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
From: Bram <p5p [...] perl.wizbit.be>
Download (untitled) / with headers
text/plain 1.9k
Citeren Rafael Garcia-Suarez <rgarciasuarez@gmail.com>: Show quoted text
> 2009/7/21 Bram <p5p@perl.wizbit.be>:
>> This seem to happen because given creates a lexical $_. It also happens when >> for/foreach is used with a lexical $_:
> > Hmm what ? No, given does not create a lexical $_ :
I didn't look at the code only at the docs and the output :/ from perldoc perlsyn: 'given(EXPR) will assign the value of EXPR to $_ within the lexical scope of the block, so it's similar to do { my $_ = EXPR; ... }' the output shows a different reference for $_ in the when block and in the s1 sub Show quoted text
> from pp_entergiven : > > if (PL_op->op_targ == 0) { > SV ** const defsv_p = &GvSV(PL_defgv); > *defsv_p = newSVsv(POPs); > SAVECLEARSV(*defsv_p); > } > else > sv_setsv(PAD_SV(PL_op->op_targ), POPs); > > What happens, at first glance, it that List::Util always uses the > global $_. (an "our $_" in the "first" block should solve the pb).
Then what does in create in pp_entergiven? Doesn't it modify PL_defgv? (I have to admit being not familiar enough with the code to really read/understand it :( ) Adding an our $_ does solve the problem: With 's1 { our $_; print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; };' the output becomes: Given/when block: when-1: $_ = SCALAR(0x942d7f0) (value: 1) s1: $_ = SCALAR(0x942d500) (value: a) block: $_ = SCALAR(0x942d500) (value: a) when-2: $_ = SCALAR(0x942d7f0) (value: 1) But why is this be nessesary? If given() does not create a lexical $_ then shouldn't the $_ in the block be the same as the global $_? Show quoted text
> > We provide UNDERBAR and dUNDERBAR macros to access the current $_, be > it lexical or global. > > However we don't have (yet) an API to localize the current $_ as > needed in grep-like functions. > > I suppose that code from pp_grepstart could be copied in List::Util to > solve the bug.
That would only work for the XS version right? (There is also a Pure Perl version...) Best regards, Bram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Tue, 21 Jul 2009 12:45:04 +0200
To: Bram <p5p [...] perl.wizbit.be>
From: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
Download (untitled) / with headers
text/plain 2.3k
2009/7/21 Bram <p5p@perl.wizbit.be>: Show quoted text
> Citeren Rafael Garcia-Suarez <rgarciasuarez@gmail.com>: >
>> 2009/7/21 Bram <p5p@perl.wizbit.be>:
>>> >>> This seem to happen because given creates a lexical $_. It also happens >>> when >>> for/foreach is used with a lexical $_:
>> >> Hmm what ? No, given does not create a lexical $_ :
> > I didn't look at the code only at the docs and the output :/ > > from perldoc perlsyn: > 'given(EXPR) will assign the value of EXPR to $_ within the lexical scope of > the block, so it's similar to do { my $_ = EXPR; ... }' > > the output shows a different reference for $_ in the when block and in the > s1 sub > >
>> from pp_entergiven : >> >>    if (PL_op->op_targ == 0) { >>        SV ** const defsv_p = &GvSV(PL_defgv); >>        *defsv_p = newSVsv(POPs); >>        SAVECLEARSV(*defsv_p); >>    } >>    else >>        sv_setsv(PAD_SV(PL_op->op_targ), POPs); >> >> What happens, at first glance, it that List::Util always uses the >> global $_. (an "our $_" in the "first" block should solve the pb).
> > Then what does in create in pp_entergiven? > Doesn't it modify PL_defgv? > (I have to admit being not familiar enough with the code to really > read/understand it :( )
Ah, you're right. The parser has this line : switch : label GIVEN '(' remember mydefsv mexpr ')' mblock where mydefsv is an empty rule that lexicalizes $_. But then the code I pasted above could probably be simplified. Show quoted text
> Adding an our $_ does solve the problem: > With 's1 { our $_; print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; };' the > output becomes: > > Given/when block: >        when-1:  $_ = SCALAR(0x942d7f0) (value: 1) >        s1:      $_ = SCALAR(0x942d500) (value: a) >        block:   $_ = SCALAR(0x942d500) (value: a) >        when-2:  $_ = SCALAR(0x942d7f0) (value: 1) > > > But why is this be nessesary? > If given() does not create a lexical $_ then shouldn't the $_ in the block > be the same as the global $_? >
>> >> We provide UNDERBAR and dUNDERBAR macros to access the current $_, be >> it lexical or global. >> >> However we don't have (yet) an API to localize the current $_ as >> needed in grep-like functions. >> >> I suppose that code from pp_grepstart could be copied in List::Util to >> solve the bug.
> > That would only work for the XS version right? > (There is also a Pure Perl version...)
Yes.
CC: Bram <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 17:50:39 +0100
To: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 818b
On Tue, Jul 21, 2009 at 12:45:04PM +0200, Rafael Garcia-Suarez wrote: Show quoted text
> Ah, you're right. The parser has this line : > switch : label GIVEN '(' remember mydefsv mexpr ')' mblock > where mydefsv is an empty rule that lexicalizes $_. > But then the code I pasted above could probably be simplified.
So if I've understood this correctly, given() adds a lexical $_ to the scope, and there's a bug in List::Util::first in that it doesn't work with a lexical $_? So not a bug in given/smartmatch? use List::Util qw/first/; print "ok outside\n" if first { $_ } 1; { my $_ = 0; print "ok inside\n" if first { $_ } 1; } outputs: ok outside -- Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 19:16:17 +0200
To: perl5-porters [...] perl.org
From: Bram <p5p [...] perl.wizbit.be>
Download (untitled) / with headers
text/plain 1.2k
Citeren Dave Mitchell <davem@iabyn.com>: Show quoted text
> On Tue, Jul 21, 2009 at 12:45:04PM +0200, Rafael Garcia-Suarez wrote:
>> Ah, you're right. The parser has this line : >> switch : label GIVEN '(' remember mydefsv mexpr ')' mblock >> where mydefsv is an empty rule that lexicalizes $_. >> But then the code I pasted above could probably be simplified.
> > > So if I've understood this correctly, given() adds a lexical $_ to the > scope, and there's a bug in List::Util::first in that it doesn't work with > a lexical $_? So not a bug in given/smartmatch?
I'm not sure if 'bug' is the correct word. What happens: (example with for instead of given) #!/usr/bin/perl -l for my $_ (1) { my $c = sub { print $_ }; $c->(); } sub foo { my $code = shift; $_ = "abc"; $code->(); } __END__ $c is a closure and closes over $_. It then passes the code reference to the function foo which modifies the global $_ and calls the closure. But: the closure closes over $_ so it will always uses the value 1... There are, as fas as I can see, two solutions: 1) modify given() so it doesn't use a lexical $_. 2) update the documentation for given() and make it more explicit that it uses a lexical $_ and that every block/code reference inside it needs our $_; before using $_. Best regards, Bram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 19:05:52 +0100
To: Bram <p5p [...] perl.wizbit.be>
From: Dave Mitchell <davem [...] iabyn.com>
On Fri, Jul 24, 2009 at 07:16:17PM +0200, Bram wrote: Show quoted text
> Citeren Dave Mitchell <davem@iabyn.com>: >
>> On Tue, Jul 21, 2009 at 12:45:04PM +0200, Rafael Garcia-Suarez wrote:
>>> Ah, you're right. The parser has this line : >>> switch : label GIVEN '(' remember mydefsv mexpr ')' mblock >>> where mydefsv is an empty rule that lexicalizes $_. >>> But then the code I pasted above could probably be simplified.
>> >> >> So if I've understood this correctly, given() adds a lexical $_ to the >> scope, and there's a bug in List::Util::first in that it doesn't work with >> a lexical $_? So not a bug in given/smartmatch?
> > I'm not sure if 'bug' is the correct word.
Well, use List::Util qw/first/; { my $_ = 0; print "ok grep \n" if grep { $_ } 1; print "ok first\n" if first { $_ } 1; } outputs ok grep So, the behaviour of first() could be described as unexpected, to say the least. I think the correct behaviour of first() would be to to modify the $_ in the caller's scope rather than what's currently in scope. -- Nothing ventured, nothing lost.
CC: Bram <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 22:42:28 +0200
To: Dave Mitchell <davem [...] iabyn.com>
From: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
Download (untitled) / with headers
text/plain 503b
2009/7/24 Dave Mitchell wrote: Show quoted text
> So if I've understood this correctly, given() adds a lexical $_ to the > scope, and there's a bug in List::Util::first in that it doesn't work with > a lexical $_? So not a bug in given/smartmatch?
Yes, although I'm not 100% sure that pp_given does exactly the right thing with the pad. List::Util::first needs to assign to the lexical $_ in the pad if there is one. -- The world is independent of my will. -- Wittgenstein, Tractatus Logico-Philosophicus, 6.373
CC: Bram <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org, Graham Barr <gbarr [...] pobox.com>
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 23:10:01 +0200
To: Dave Mitchell <davem [...] iabyn.com>
From: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
Download (untitled) / with headers
text/plain 1.7k
2009/7/24 Rafael Garcia-Suarez <rgarciasuarez@gmail.com>: Show quoted text
> 2009/7/24 Dave Mitchell wrote:
>> So if I've understood this correctly, given() adds a lexical $_ to the >> scope, and there's a bug in List::Util::first in that it doesn't work with >> a lexical $_? So not a bug in given/smartmatch?
> > Yes, although I'm not 100% sure that pp_given does exactly the right > thing with the pad. List::Util::first needs to assign to the lexical $_ > in the pad if there is one.
Yes, the patch below solves your reduced test case, the one with grep and first, but doesn't solve the original problem, which denotes probably another bug in pp_given (that constructs a lexical $_ without a padmy op.) Graham, would you consider an improved version of the patch below for List::Util, to make first work with lexical $_ ? I don't think there are other areas in List::Util that need a similar modification. --- a/ext/List-Util/ListUtil.xs +++ b/ext/List-Util/ListUtil.xs @@ -329,16 +329,25 @@ CODE: I32 gimme = G_SCALAR; SV **args = &PL_stack_base[ax]; CV *cv; + PADOFFSET padoff_du = find_rundefsvoffset(); + bool has_global_underbar = padoff_du == NOT_IN_PAD + || PAD_COMPNAME_FLAGS_isOUR(padoff_du); if(items <= 1) { XSRETURN_UNDEF; } cv = sv_2cv(block, &stash, &gv, 0); PUSH_MULTICALL(cv); - SAVESPTR(GvSV(PL_defgv)); + if (has_global_underbar) + SAVESPTR(GvSV(PL_defgv)); + else + SAVESPTR(PAD_SVl(padoff_du)); for(index = 1 ; index < items ; index++) { - GvSV(PL_defgv) = args[index]; + if (has_global_underbar) + GvSV(PL_defgv) = args[index]; + else + PAD_SVl(padoff_du) = args[index]; MULTICALL; if (SvTRUE(*PL_stack_sp)) { POP_MULTICALL;
CC: Dave Mitchell <davem [...] iabyn.com>, Bram <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 18:44:48 -0400
To: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 615b
On Fri, Jul 24, 2009 at 4:42 PM, Rafael Garcia-Suarez < rgarciasuarez@gmail.com> wrote: Show quoted text
> 2009/7/24 Dave Mitchell wrote:
> > So if I've understood this correctly, given() adds a lexical $_ to the > > scope, and there's a bug in List::Util::first in that it doesn't work
> with
> > a lexical $_? So not a bug in given/smartmatch?
> > Yes, although I'm not 100% sure that pp_given does exactly the right > thing with the pad. List::Util::first needs to assign to the lexical $_ > in the pad if there is one. >
How are the Pure Perl implementation of List::Util and countless other Perl (&) subs suppose to do that?
CC: "Rafael Garcia-Suarez" <rgarciasuarez [...] gmail.com>, "Dave Mitchell" <davem [...] iabyn.com>, "Bram" <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 17:28:22 -0700 (PDT)
To: "Eric Brine" <ikegami [...] adaelis.com>
From: "Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>
Download (untitled) / with headers
text/plain 742b
On Fri, July 24, 2009 3:44 pm, Eric Brine wrote: Show quoted text
> On Fri, Jul 24, 2009 at 4:42 PM, Rafael Garcia-Suarez < > rgarciasuarez@gmail.com> wrote:
>> 2009/7/24 Dave Mitchell wrote:
>>> So if I've understood this correctly, given() adds a lexical $_ to >>> the scope, and there's a bug in List::Util::first in that it doesn't >>> work with >>> a lexical $_? So not a bug in given/smartmatch?
>> >> Yes, although I'm not 100% sure that pp_given does exactly the right >> thing with the pad. List::Util::first needs to assign to the lexical $_ >> in the pad if there is one.
> > How are the Pure Perl implementation of List::Util and countless other > Perl (&) subs suppose to do that?
Add a reference to the proper $_ to the caller() return list?
CC: Dave Mitchell <davem [...] iabyn.com>, Bram <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 19:30:12 -0500
To: Rafael Garcia-Suarez <rgarciasuarez [...] gmail.com>
From: Graham Barr <gbarr [...] pobox.com>
Download (untitled) / with headers
text/plain 1.4k
On Jul 24, 2009, at 4:10 PM, Rafael Garcia-Suarez wrote: Show quoted text
> Graham, would you consider an improved version of the patch below for > List::Util, to make first work with lexical $_ ? I don't think there > are other areas in List::Util that need a similar modification.
Sure. first is the only place in List::Util where $_ is used. This patch would work for the XS version, but what about the pure Perl ? Although should the code passed to first call a sub, that code will not see $_, but I suspect grep has the same issue there Graham. Show quoted text
> > --- a/ext/List-Util/ListUtil.xs > +++ b/ext/List-Util/ListUtil.xs > @@ -329,16 +329,25 @@ CODE: > I32 gimme = G_SCALAR; > SV **args = &PL_stack_base[ax]; > CV *cv; > + PADOFFSET padoff_du = find_rundefsvoffset(); > + bool has_global_underbar = padoff_du == NOT_IN_PAD > + || PAD_COMPNAME_FLAGS_isOUR(padoff_du); > > if(items <= 1) { > XSRETURN_UNDEF; > } > cv = sv_2cv(block, &stash, &gv, 0); > PUSH_MULTICALL(cv); > - SAVESPTR(GvSV(PL_defgv)); > + if (has_global_underbar) > + SAVESPTR(GvSV(PL_defgv)); > + else > + SAVESPTR(PAD_SVl(padoff_du)); > > for(index = 1 ; index < items ; index++) { > - GvSV(PL_defgv) = args[index]; > + if (has_global_underbar) > + GvSV(PL_defgv) = args[index]; > + else > + PAD_SVl(padoff_du) = args[index]; > MULTICALL; > if (SvTRUE(*PL_stack_sp)) { > POP_MULTICALL; >
CC: "Eric Brine" <ikegami [...] adaelis.com>, "Rafael Garcia-Suarez" <rgarciasuarez [...] gmail.com>, "Dave Mitchell" <davem [...] iabyn.com>, "Bram" <p5p [...] perl.wizbit.be>, perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Fri, 24 Jul 2009 20:05:56 -0700 (PDT)
To: "Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>
From: "Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>
Download (untitled) / with headers
text/plain 653b
On Fri, July 24, 2009 5:28 pm, Yitzchak Scott-Thoennes wrote: Show quoted text
> On Fri, July 24, 2009 3:44 pm, Eric Brine wrote:
>> On Fri, Jul 24, 2009 at 4:42 PM, Rafael Garcia-Suarez wrote:
>>> Yes, although I'm not 100% sure that pp_given does exactly the right >>> thing with the pad. List::Util::first needs to assign to the lexical >>> $_ in the pad if there is one.
>> >> How are the Pure Perl implementation of List::Util and countless other >> Perl (&) subs suppose to do that?
> > Add a reference to the proper $_ to the caller() return list?
Err, never mind, that wouldn't tell you what $_ was in scope of the sub if the sub wasn't in the caller's scope.
CC: perl [...] sluka.de
Subject: $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 18:55:16 +0100
To: perlbug [...] perl.org
From: fany [...] cpan.org
Download (untitled) / with headers
text/plain 3.9k
This is a bug report for perl from fany@cpan.org, generated with the help of perlbug 1.39 running under perl 5.14.2. ----------------------------------------------------------------- [Please describe your issue here] When I use a function which expects a codeblock as first argument, like List::Util::first(), within a "given" block, then $_ within that codeblock does not work properly, but keeps the value of the $_ from the "given" block. Or, in other words, the test script below will output the following: 1 - 2 - 3 - grep OK! 1 - first OK! 1 - fpp OK! 1 - 2 - 3 - grep within given OK! 0 - 0 - 0 - 0 - 0 - 0 - Kind regards, fany - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/usr/bin/perl -w use 5.01; use strict; use List::Util qw(first); sub fpp(&@) { my $sub = shift; $sub->($_) and return 1 for @_; ''; } my @array = 1 .. 3; my $where = ''; print "grep$where OK!" if grep { print "$_ - "; $_ } @array; print "\n"; print "first$where OK!" if first { print "$_ - "; $_ } @array; print "\n"; print "fpp$where OK!" if fpp { print "$_ - "; $_ } @array; print "\n"; $where = ' within given'; given (0) { default { print "grep$where OK!" if grep { print "$_ - "; $_ } @array; print "\n"; print "first$where OK!" if first { print "$_ - "; $_ } @array; print "\n"; print "fpp$where OK!" if fpp { print "$_ - "; $_ } @array; print "\n"; } } [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.14.2: Configured by fany at Mon Oct 3 11:31:06 CEST 2011. Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=linux, osvers=2.6.37.6-0.5-desktop, archname=x86_64-linux uname='linux homer 2.6.37.6-0.5-desktop #1 smp preempt 2011-04-25 21:48:33 +0200 x86_64 x86_64 x86_64 gnulinux ' config_args='' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.5.1 20101208 [gcc-4_5-branch revision 167585]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.11.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' Locally applied patches: --- @INC for perl 5.14.2: /usr/local/lib/perl5/site_perl/5.14.2/x86_64-linux /usr/local/lib/perl5/site_perl/5.14.2 /usr/local/lib/perl5/5.14.2/x86_64-linux /usr/local/lib/perl5/5.14.2 /etc/perl . --- Environment for perl 5.14.2: HOME=/home/fany LANG=de_DE.UTF-8 LANGUAGE= LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/fany/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/sbin:/usr/sbin:/usr/sbin PERL_BADLANG (unset) SHELL=/bin/bash
RT-Send-CC: perl5-porters [...] perl.org, perl.p5p [...] rjbs.manxome.org
On Sat Dec 10 09:55:36 2011, fany@cpan.org wrote: Show quoted text
> > This is a bug report for perl from fany@cpan.org, > generated with the help of perlbug 1.39 running under perl 5.14.2. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > > When I use a function which expects a codeblock as first > argument, like List::Util::first(), within a "given" block, > then $_ within that codeblock does not work properly, but > keeps the value of the $_ from the "given" block. > > Or, in other words, the test script below will output the > following: > > 1 - 2 - 3 - grep OK! > 1 - first OK! > 1 - fpp OK! > 1 - 2 - 3 - grep within given OK! > 0 - 0 - 0 - > 0 - 0 - 0 - > > Kind regards, > fany
This is a known issue, #67694. given does an implicit ‘my $_’. See also ticket #90018 and ticket #53186 (marked as resolved, even though it isn’t). RJBS: Would you be adverse to changing ‘given’ to alias $_ properly, or is it too close to 5.16 at this stage? -- Father Chrysostomos
RT-Send-CC: fany [...] cpan.org, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
On Sat Dec 10 11:51:52 2011, sprout wrote: Show quoted text
> On Sat Dec 10 09:55:36 2011, fany@cpan.org wrote:
> > > > This is a bug report for perl from fany@cpan.org, > > generated with the help of perlbug 1.39 running under perl 5.14.2. > > > > > > ----------------------------------------------------------------- > > [Please describe your issue here] > > > > > > When I use a function which expects a codeblock as first > > argument, like List::Util::first(), within a "given" block, > > then $_ within that codeblock does not work properly, but > > keeps the value of the $_ from the "given" block. > > > > Or, in other words, the test script below will output the > > following: > > > > 1 - 2 - 3 - grep OK! > > 1 - first OK! > > 1 - fpp OK! > > 1 - 2 - 3 - grep within given OK! > > 0 - 0 - 0 - > > 0 - 0 - 0 - > > > > Kind regards, > > fany
> > This is a known issue, #67694. given does an implicit ‘my $_’. See > also ticket #90018 and ticket #53186 (marked as resolved, even though it > isn’t).
BTW, the easiest workaround is to use ‘for’ instead of ‘given’. You can still use ‘when’ inside ‘for’. -- Father Chrysostomos
CC: perl5-porters [...] perl.org, perl.p5p [...] rjbs.manxome.org
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 13:04:20 -0700
To: perlbug-followup [...] perl.org
From: Tom Christiansen <tchrist [...] perl.com>
Download (untitled) / with headers
text/plain 595b
"Father Chrysostomos via RT" <perlbug-followup@perl.org> wrote on Sat, 10 Dec 2011 11:51:53 PST: Show quoted text
> This is a known issue, #67694. given does an implicit ‘my $_’. See > also ticket #90018 and ticket #53186 (marked as resolved, even though > it isn’t).
Show quoted text
> RJBS: Would you be adverse to changing ‘given’ to alias $_ properly, > or is it too close to 5.16 at this stage?
I've always felt this to be a bug, and would like to see some way to get the more expected/normal behavior. I just don't know how to make the omelette without breaking any eggs (read, existing code). --tom
CC: perlbug-followup [...] perl.org, perl5-porters [...] perl.org, perl.p5p [...] rjbs.manxome.org
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 21:09:26 +0100
To: Tom Christiansen <tchrist [...] perl.com>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 343b
On Sat, Dec 10, 2011 at 9:04 PM, Tom Christiansen <tchrist@perl.com> wrote: Show quoted text
> I've always felt this to be a bug, and would like to see some way > to get the more expected/normal behavior.  I just don't know how > to make the omelette without breaking any eggs (read, existing code).
I'm afraid the only solution is «use 5.016;» :-| Leon
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 716b
On Sat Dec 10 12:04:57 2011, tom christiansen wrote: Show quoted text
> "Father Chrysostomos via RT" <perlbug-followup@perl.org> wrote > on Sat, 10 Dec 2011 11:51:53 PST: >
> > This is a known issue, #67694. given does an implicit ‘my $_’. See > > also ticket #90018 and ticket #53186 (marked as resolved, even though > > it isn’t).
>
> > RJBS: Would you be adverse to changing ‘given’ to alias $_ properly, > > or is it too close to 5.16 at this stage?
> > I've always felt this to be a bug, and would like to see some way > to get the more expected/normal behavior. I just don't know how > to make the omelette without breaking any eggs (read, existing code).
Use powdered eggs. :-) -- Father Chrysostomos
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1015b
On Sat Dec 10 12:10:19 2011, LeonT wrote: Show quoted text
> On Sat, Dec 10, 2011 at 9:04 PM, Tom Christiansen <tchrist@perl.com>
wrote: Show quoted text
> > I've always felt this to be a bug, and would like to see some way > > to get the more expected/normal behavior. I just don't know how > > to make the omelette without breaking any eggs (read, existing code).
> > I'm afraid the only solution is «use 5.016;» :-|
There is this comment in feature.pm: # TODO: # - think about versioned features (use feature switch => 2) I think that approach would cause too much confusion. feature.pm deals with aspects of the perl core itself, so having multiple orthogonal sets of version numbers for the perl core (as opposed to modules included with the core) would be undesirable. I propose we tack the perl version number on the end and make it a new named feature: ‘switch5.16’. It may not be pretty, but it follows the same format of the number that version bundles use, and the meaning is immediately apparent. -- Father Chrysostomos
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 18:41:41 -0500
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 759b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12-10T14:51:53] Show quoted text
> RJBS: Would you be adverse to changing ‘given’ to alias $_ properly, or > is it too close to 5.16 at this stage?
I agree, *strenuously* that 'given' is a big problem on several fronts, and the lexical $_ is certainly one of the more widely-felt pains. I think fixing it via something like :5.16 containing given5_16 is not nuts, but I've got to say: I think we should be considering deprecating given for straight-up removal. In the meantime, would we want to consider warning on closing over lexical $_ inside a given? Does anybody ever do this on purpose? This email did not get a lot of deep thought. I composed it during a brief break in tree-trimming. -- rjbs
CC: perl5-porters [...] perl.org
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 17:48:27 -0600
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 947b
On Sat, Dec 10, 2011 at 06:41:41PM -0500, Ricardo Signes wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12-10T14:51:53]
> > RJBS: Would you be adverse to changing ‘given’ to alias $_ properly, or > > is it too close to 5.16 at this stage?
> > I agree, *strenuously* that 'given' is a big problem on several fronts, and the > lexical $_ is certainly one of the more widely-felt pains. > > I think fixing it via something like :5.16 containing given5_16 is not nuts, > but I've got to say: I think we should be considering deprecating given for > straight-up removal.
+1. I also don't think it's worth trying to reintroduce new semantics for given without also fixing the other issues with it (like smartmatch). Show quoted text
> In the meantime, would we want to consider warning on closing over lexical $_ > inside a given? Does anybody ever do this on purpose?
Probably +1, although I haven't given it much thought yet. -doy
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
RT-Send-CC: perl5-porters [...] perl.org
On Sat Dec 10 15:42:18 2011, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12- > 10T14:51:53]
> > RJBS: Would you be adverse to changing ‘given’ to alias $_ properly,
> or
> > is it too close to 5.16 at this stage?
> > I agree, *strenuously* that 'given' is a big problem on several > fronts, and the > lexical $_ is certainly one of the more widely-felt pains. > > I think fixing it via something like :5.16 containing given5_16 is not > nuts, > but I've got to say: I think we should be considering deprecating > given for > straight-up removal.
From a maintenance standpoint, +1000! But I am loath to break anyone’s code. On the other hand, it has only been a short while since it was introduced, and almost everyone who has tried it has run into problems. So I won’t get in the way of its removal. Show quoted text
> > In the meantime, would we want to consider warning on closing over > lexical $_ > inside a given?
Absolutely. Show quoted text
> Does anybody ever do this on purpose?
I doubt it. -- Father Chrysostomos
CC: perl5-porters [...] perl.org
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 19:52:41 -0500
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: David Golden <xdaveg [...] gmail.com>
On Sat, Dec 10, 2011 at 6:41 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: Show quoted text
> I agree, *strenuously* that 'given' is a big problem on several fronts, and the > lexical $_ is certainly one of the more widely-felt pains. > > I think fixing it via something like :5.16 containing given5_16 is not nuts, > but I've got to say: I think we should be considering deprecating given for > straight-up removal.
I'm supportive only if we replaced it with a decent switch construct or deprecated just the broken parts of it. It doesn't have to be a "smart" switch -- just a switch against scalars would be fine. (Nit -- I suppose the challenge is numeric or string matching -- maybe a "numeric $scalar" or "string $scalar" keyword like "scalar" for that context?) For anything "smart", we can/should use if/elsif. Show quoted text
> In the meantime, would we want to consider warning on closing over lexical $_ > inside a given?  Does anybody ever do this on purpose?
A warning sounds reasonable and anyone doing it on purpose can turn off the warning. -- David
Subject: Fwd: [perl #105850] $_ does not work as expected within "given" block
Date: Sat, 10 Dec 2011 22:15:16 -0500
To: perl5-porters [...] perl.org
From: Chris Prather <chris [...] prather.org>
Download (untitled) / with headers
text/plain 2.1k
I missed the list (my apologies David). -Chris Show quoted text
---------- Forwarded message ---------- From: Chris Prather <chris@prather.org> Date: Sat, Dec 10, 2011 at 10:13 PM Subject: Re: [perl #105850] $_ does not work as expected within "given" block To: David Golden <xdaveg@gmail.com> On Sat, Dec 10, 2011 at 7:52 PM, David Golden <xdaveg@gmail.com> wrote:
> On Sat, Dec 10, 2011 at 6:41 PM, Ricardo Signes > <perl.p5p@rjbs.manxome.org> wrote:
>> I agree, *strenuously* that 'given' is a big problem on several fronts, and the >> lexical $_ is certainly one of the more widely-felt pains. >> >> I think fixing it via something like :5.16 containing given5_16 is not nuts, >> but I've got to say: I think we should be considering deprecating given for >> straight-up removal.
> > I'm supportive only if we replaced it with a decent switch construct > or deprecated just the broken parts of it.  It doesn't have to be a > "smart" switch -- just a switch against scalars would be fine.  (Nit > -- I suppose the challenge is numeric or string matching -- maybe a > "numeric $scalar" or "string $scalar" keyword like "scalar" for that > context?)  For anything "smart", we can/should use if/elsif.
Switch and Smart Matching are not equivalent. I'm guessing (hoping?) that Ric is simply talking about deprecating `given` and not `when`. Which would leave the more Perl5-ish: for ($var) {   when (defined) { ... }   when (m/foo/) { ... }   when ($_ eq 'bar') { ... } } That is all you need for switch is a topicalizer (for) and a test that exits the block on success (when). These cover 99% of the use cases I've seen in the wild for given/when. Fact is that I try very hard to only use given/when in cases where I know it fits within one of the special cases (see above). Removing given() wouldn't be that painful to most of the code I'm responsible for, nor honestly would removing SmartMatch. Removing when() however would make me cry.
>> In the meantime, would we want to consider warning on closing over lexical $_ >> inside a given?  Does anybody ever do this on purpose?
> > A warning sounds reasonable and anyone doing it on purpose can turn > off the warning.
no warnings "given"; # none 'expected'; :) -Chris
CC: perl5-porters [...] perl.org
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
Date: Sun, 11 Dec 2011 15:04:34 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 815b
On Sun, Dec 11, 2011 at 12:41 AM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: Show quoted text
> I agree, *strenuously* that 'given' is a big problem on several fronts, and the > lexical $_ is certainly one of the more widely-felt pains. > > I think fixing it via something like :5.16 containing given5_16 is not nuts, > but I've got to say: I think we should be considering deprecating given for > straight-up removal. > > In the meantime, would we want to consider warning on closing over lexical $_ > inside a given?  Does anybody ever do this on purpose?
It's possible to do the right thing AFAIK, it's just that no one does it. Ironically, it's quite easy and sane to do in XS, but really hard in pure perl. I'd like a way to flag a function as being able to handle lexical $_ if we are going to make this warn. Leon
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1021b
On Sun Dec 11 06:05:24 2011, LeonT wrote: Show quoted text
> On Sun, Dec 11, 2011 at 12:41 AM, Ricardo Signes > <perl.p5p@rjbs.manxome.org> wrote:
> > I agree, *strenuously* that 'given' is a big problem on several
> fronts, and the
> > lexical $_ is certainly one of the more widely-felt pains. > > > > I think fixing it via something like :5.16 containing given5_16 is
> not nuts,
> > but I've got to say: I think we should be considering deprecating
> given for
> > straight-up removal. > > > > In the meantime, would we want to consider warning on closing over
> lexical $_
> > inside a given? �Does anybody ever do this on purpose?
> > It's possible to do the right thing AFAIK, it's just that no one does > it. Ironically, it's quite easy and sane to do in XS, but really hard > in pure perl. I'd like a way to flag a function as being able to > handle lexical $_ if we are going to make this warn.
What’s so ironic is that, if called functions can see it, $_ isn’t really lexical any more, is it? -- Father Chrysostomos
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Mon, 12 Dec 2011 15:20:20 -0500
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 708b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12-11T09:48:24] Show quoted text
> On Sun Dec 11 06:05:24 2011, LeonT wrote:
> > It's possible to do the right thing AFAIK, it's just that no one does > > it. Ironically, it's quite easy and sane to do in XS, but really hard > > in pure perl. I'd like a way to flag a function as being able to > > handle lexical $_ if we are going to make this warn.
given ($x) { no warnings 'closure'; my $sub = sub { warn $_ }; } Something along those lines? Show quoted text
> What’s so ironic is that, if called functions can see it, $_ isn’t > really lexical any more, is it?
Well, they're seeing it because they closed over it, right? That's still lexical. -- rjbs
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Mon Dec 12 12:20:53 2011, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12- > 11T09:48:24]
> > On Sun Dec 11 06:05:24 2011, LeonT wrote:
> > > It's possible to do the right thing AFAIK, it's just that no one
> does
> > > it. Ironically, it's quite easy and sane to do in XS, but really
> hard
> > > in pure perl. I'd like a way to flag a function as being able to > > > handle lexical $_ if we are going to make this warn.
> > given ($x) { > no warnings 'closure'; > my $sub = sub { warn $_ }; > } > > Something along those lines?
I think Leon Timmermans meant that functions like Scalar::Util::first should be able to suppress that warning in their *arguments*. given ($x) { when(first { ... $_ ... }); # no warning when(other_func { ... $_ ... }); # warning } Show quoted text
>
> > What’s so ironic is that, if called functions can see it, $_ isn’t > > really lexical any more, is it?
> > Well, they're seeing it because they closed over it, right? That's > still > lexical.
I’m referring to the ability of XS modules (like Scalar::Util::first) to access the lexical $_ of the caller. Scalar::Util::first doesn’t actually do that, so it’s not a good example, but there is an API for it. -- Father Chrysostomos
CC: perl5-porters [...] perl.org
Subject: Re: [perl #67694] List::Util attaching to the wrong $_ when used inside given/when construct
Date: Sun, 18 Dec 2011 16:39:24 +0100
To: perlbug-followup [...] perl.org
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 784b
On Mon, Dec 12, 2011 at 10:03 PM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: Show quoted text
> I think Leon Timmermans meant that functions like Scalar::Util::first > should be able to suppress that warning in their *arguments*. > > given ($x) { >    when(first { ... $_ ... }); # no warning >    when(other_func { ... $_ ... }); # warning > }
Exactly. Show quoted text
> I’m referring to the ability of XS modules (like Scalar::Util::first) to > access the lexical $_ of the caller.  Scalar::Util::first doesn’t > actually do that, so it’s not a good example, but there is an API for it.
Though I'm not sure any module uses it currently TBH, ppport and some unicode symbols generate too much noise for grep.cpan.me to give clear results but I didn't see any positives so far. Leon
Fixed by b5a648148c.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org