Mailing List Archive: Perl: porters

[perl #113818] List::Util::first() don't work into when() context

1 2

View All

Index | Next | Previous | View Threaded

perlbug-followup at perl

Jun 24, 2012, 11:25 AM

Post #1 of 43 (296 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context

# New Ticket Created by Joaquin Ferrero
# Please include the string: [perl #113818]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818 >

This is a bug report for perl from explorer [at] joaquinferrero,
generated with the help of perlbug 1.39 running under perl 5.10.1.

-----------------------------------------------------------------

Example:
-------------------------8<---------------------------
#!/usr/bin/env perl
use v5.10;
use strict;
use warnings;
use List::Util "first";

say $List::Util::VERSION;

my @probe = (
'w83793-i2c-0-2f',
'Adapter: SMBus I801 adapter at 1100',
'CPU Core: +1.16 V (min = +0.92 V, max = +1.49 V)',
'+1.5V: +1.48 V (min = +1.42 V, max = +1.58 V)',
'fan1: 1841 RPM (min = 712 RPM)',
'CPU fan: 0 RPM (min = 712 RPM) ALARM',
'CPU Temp: +54.0°C (high = +75.0°C, hyst = +70.0°C) sensor = thermal diode',
);

my @temp = @probe;
my $cputemp = first { /^CPU Temp/ } @temp;
$cputemp //= '';
say "[$cputemp]";

my $item = 'temp1';

given ($item) {
when ('temp1') {
my @temp = @probe;
my $cputemp = first { /^CPU Temp/ } @temp;
$cputemp //= '';
say "[$cputemp]";
}
}
-------------------------8<---------------------------
OUTPUT:
1.23
[.CPU Temp: +54.0°C (high = +75.0°C, hyst = +70.0°C) sensor = thermal diode]
[]
-------------------------8<---------------------------
Probed:
Perl v5.10.1 - Linux 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux
Perl v5.16.0 - Linux 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux
Perl v5.14.2 - Linux 3.1.10-1.9-desktop #1 SMP PREEMPT Thu Apr 5 18:48:38 UTC 2012 (4a97ec8) x86_64 GNU/Linux

-----------------------------------------------------------------
---
Flags:
category=library
severity=high
module=List::Util
---
Site configuration information for perl 5.10.1:

Configured by Debian Project at Thu Jun 30 22:25:10 UTC 2011.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

Platform:
osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux-gnu-thread-multi
uname='linux brahms 2.6.32-5-amd64 #1 smp tue jun 14 09:42:28 utc 2011 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.1 -Dsitearch=/usr/local/lib/perl/5.10.1 -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.1 -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 -fstack-protector -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 -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.4.5', 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 /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.11.2.so, so=so, useshrplib=true, libperl=libperl.so.5.10.1
gnulibc_version='2.11.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches:
DEBPKG:debian/arm_thread_stress_timeout - http://bugs.debian.org/501970 Raise the timeout of ext/threads/shared/t/stress.t to accommodate slower build hosts
DEBPKG:debian/cpan_config_path - Set location of CPAN::Config to /etc/perl as /usr may not be writable.
DEBPKG:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS default for modules installed from CPAN.
DEBPKG:debian/db_file_ver - http://bugs.debian.org/340047 Remove overly restrictive DB_File version check.
DEBPKG:debian/doc_info - Replace generic man(1) instructions with Debian-specific information.
DEBPKG:debian/enc2xs_inc - http://bugs.debian.org/290336 Tweak enc2xs to follow symlinks and ignore missing @INC directories.
DEBPKG:debian/errno_ver - http://bugs.debian.org/343351 Remove Errno version check due to upgrade problems with long-running processes.
DEBPKG:debian/extutils_hacks - Various debian-specific ExtUtils changes
DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to the binary targets.
DEBPKG:debian/instmodsh_doc - Debian policy doesn't install .packlist files for core or vendor.
DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as per Debian policy.
DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable.
DEBPKG:debian/m68k_thread_stress - http://bugs.debian.org/495826 Disable some threads tests on m68k for now due to missing TLS.
DEBPKG:debian/mod_paths - Tweak @INC ordering for Debian
DEBPKG:debian/module_build_man_extensions - http://bugs.debian.org/479460 Adjust Module::Build manual page extensions for the Debian Perl policy
DEBPKG:debian/perl_synopsis - http://bugs.debian.org/278323 Rearrange perl.pod
DEBPKG:debian/prune_libs - http://bugs.debian.org/128355 Prune the list of libraries wanted to what we actually need.
DEBPKG:debian/use_gdbm - Explicitly link against -lgdbm_compat in ODBM_File/NDBM_File.
DEBPKG:fixes/assorted_docs - http://bugs.debian.org/443733 [384f06a] Math::BigInt::CalcEmu documentation grammar fix
DEBPKG:fixes/net_smtp_docs - http://bugs.debian.org/100195 [rt.cpan.org #36038] Document the Net::SMTP 'Port' option
DEBPKG:fixes/processPL - http://bugs.debian.org/357264 [rt.cpan.org #17224] Always use PERLRUNINST when building perl modules.
DEBPKG:debian/perlivp - http://bugs.debian.org/510895 Make perlivp skip include directories in /usr/local
DEBPKG:fixes/pod2man-index-backslash - http://bugs.debian.org/521256 Escape backslashes in .IX entries
DEBPKG:debian/disable-zlib-bundling - Disable zlib bundling in Compress::Raw::Zlib
DEBPKG:fixes/kfreebsd_cppsymbols - http://bugs.debian.org/533098 [3b910a0] Add gcc predefined macros to $Config{cppsymbols} on GNU/kFreeBSD.
DEBPKG:debian/cpanplus_definstalldirs - http://bugs.debian.org/533707 Configure CPANPLUS to use the site directories by default.
DEBPKG:debian/cpanplus_config_path - Save local versions of CPANPLUS::Config::System into /etc/perl.
DEBPKG:fixes/kfreebsd-filecopy-pipes - http://bugs.debian.org/537555 [16f708c] Fix File::Copy::copy with pipes on GNU/kFreeBSD
DEBPKG:fixes/anon-tmpfile-dir - http://bugs.debian.org/528544 [perl #66452] Honor TMPDIR when open()ing an anonymous temporary file
DEBPKG:fixes/abstract-sockets - http://bugs.debian.org/329291 [89904c0] Add support for Abstract namespace sockets.
DEBPKG:fixes/hurd_cppsymbols - http://bugs.debian.org/544307 [eeb92b7] Add gcc predefined macros to $Config{cppsymbols} on GNU/Hurd.
DEBPKG:fixes/autodie-flock - http://bugs.debian.org/543731 Allow for flock returning EAGAIN instead of EWOULDBLOCK on linux/parisc
DEBPKG:fixes/archive-tar-instance-error - http://bugs.debian.org/539355 [rt.cpan.org #48879] Separate Archive::Tar instance error strings from each other
DEBPKG:fixes/positive-gpos - http://bugs.debian.org/545234 [perl #69056] [c584a96] Fix \\G crash on first match
DEBPKG:debian/devel-ppport-ia64-optim - http://bugs.debian.org/548943 Work around an ICE on ia64
DEBPKG:fixes/trie-logic-match - http://bugs.debian.org/552291 [perl #69973] [0abd0d7] Fix a DoS in Unicode processing [CVE-2009-3626]
DEBPKG:fixes/hppa-thread-eagain - http://bugs.debian.org/554218 make the threads-shared test suite more robust, fixing failures on hppa
DEBPKG:fixes/crash-on-undefined-destroy - http://bugs.debian.org/564074 [perl #71952] [1f15e67] Fix a NULL pointer dereference when looking for a DESTROY method
DEBPKG:fixes/tainted-errno - http://bugs.debian.org/574129 [perl #61976] [be1cf43] fix an errno stringification bug in taint mode
DEBPKG:fixes/safe-upgrade - http://bugs.debian.org/582978 Upgrade Safe.pm to 2.25, fixing CVE-2010-1974
DEBPKG:fixes/tell-crash - http://bugs.debian.org/578577 [f4817f3] Fix a tell() crash on bad arguments.
DEBPKG:fixes/format-write-crash - http://bugs.debian.org/579537 [perl #22977] [421f30e] Fix a crash in format/write
DEBPKG:fixes/arm-alignment - http://bugs.debian.org/289884 [f1c7503] Prevent gcc from optimizing the alignment test away on armel
DEBPKG:fixes/fcgi-test - Fix a failure in CGI/t/fast.t when FCGI is installed
DEBPKG:fixes/hurd-ccflags - http://bugs.debian.org/587901 Make hints/gnu.sh append to $ccflags rather than overriding them
DEBPKG:debian/squelch-locale-warnings - http://bugs.debian.org/508764 Squelch locale warnings in Debian package maintainer scripts
DEBPKG:fixes/lc-numeric-docs - http://bugs.debian.org/379329 [perl #78452] [903eb63] LC_NUMERIC documentation fixes
DEBPKG:fixes/lc-numeric-sprintf - http://bugs.debian.org/601549 [perl #78632] [b3fd614] Fix sprintf not to ignore LC_NUMERIC with constants
DEBPKG:fixes/concat-stack-corruption - http://bugs.debian.org/596105 [perl #78674] [e3393f5] Fix stack pointer corruption in pp_concat() with 'use encoding'
DEBPKG:fixes/cgi-multiline-header - http://bugs.debian.org/606995 [CVE-2010-2761 CVE-2010-4410 CVE-2010-4411] CGI.pm MIME boundary and multiline header vulnerabilities
DEBPKG:fixes/casing-taint-cve-2011-1487 - http://bugs.debian.org/622817 [perl #87336] fix unwanted taint laundering in lc(), uc() et al.
DEBPKG:fixes/safe-reval-rdo-cve-2010-1447 - [PATCH] Wrap by default coderefs returned by rdo and reval
DEBPKG:patchlevel - http://bugs.debian.org/567489 List packaged patches for 5.10.1-17squeeze2 in patchlevel.h

---
@INC for perl 5.10.1:
/etc/perl
/usr/local/lib/perl/5.10.1
/usr/local/share/perl/5.10.1
/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.1:
HOME=/home/explorer
LANG=es_ES.UTF-8
LANGUAGE=es:en
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/home/explorer/perl5/perlbrew/bin:/home/explorer/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/java/jdk1.6.0_07
PERLBREW_BASHRC_VERSION=0.43
PERLBREW_HOME=/home/explorer/.perlbrew
PERLBREW_MANPATH=
PERLBREW_PATH=/home/explorer/perl5/perlbrew/bin
PERLBREW_PERL=
PERLBREW_ROOT=/home/explorer/perl5/perlbrew
PERLBREW_VERSION=0.43
PERL_BADLANG (unset)
SHELL=/bin/bash

b2gills at gmail

Jun 26, 2012, 5:36 PM

Post #2 of 43 (293 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Sun, Jun 24, 2012 at 1:25 PM, Joaquin Ferrero
<perlbug-followup [at] perl> wrote:
> # New Ticket Created by Joaquin Ferrero
> # Please include the string: [perl #113818]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818 >
>
>
>
> This is a bug report for perl from explorer [at] joaquinferrero,
> generated with the help of perlbug 1.39 running under perl 5.10.1.
>
>
> -----------------------------------------------------------------
>
> Example:
> -------------------------8<---------------------------
> #!/usr/bin/env perl
> use v5.10;
> use strict;
> use warnings;
> use List::Util "first";
>
> say $List::Util::VERSION;
>
> my @probe = (
> 'w83793-i2c-0-2f',
> 'Adapter: SMBus I801 adapter at 1100',
> 'CPU Core: +1.16 V (min = +0.92 V, max = +1.49 V)',
> '+1.5V: +1.48 V (min = +1.42 V, max = +1.58 V)',
> 'fan1: 1841 RPM (min = 712 RPM)',
> 'CPU fan: 0 RPM (min = 712 RPM) ALARM',
> 'CPU Temp: +54.0°C (high = +75.0°C, hyst = +70.0°C) sensor = thermal diode',
> );
>
> my @temp = @probe;
> my $cputemp = first { /^CPU Temp/ } @temp;
> $cputemp //= '';
> say "[$cputemp]";
>
> my $item = 'temp1';
>
> given ($item) {
> when ('temp1') {
> my @temp = @probe;
> my $cputemp = first { /^CPU Temp/ } @temp;
> $cputemp //= '';
> say "[$cputemp]";
> }
> }
> -------------------------8<---------------------------
> OUTPUT:
> 1.23
> [.CPU Temp: +54.0°C (high = +75.0°C, hyst = +70.0°C) sensor = thermal diode]
> []
> -------------------------8<---------------------------

This is because 'given' uses a lexical '$_', and 'first' also uses '$_';

If you replace 'given' with 'for' it works as expected

perlbug-comment at perl

Jun 27, 2012, 4:35 AM

Post #3 of 43 (284 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

Alternately, you can continue using given/when and refer to $::_ in your first block, rather than
$_.

I suggest ditching given/when, though.

rgs at consttype

Jun 27, 2012, 5:37 AM

Post #4 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-comment [at] perl> wrote:
> Alternately, you can continue using given/when and refer to $::_ in your first block, rather than
> $_.

C<our $_> should work, too.

> I suggest ditching given/when, though.

Or fix the internal macro that gives access to $_ from XS.

fawaka at gmail

Jun 27, 2012, 6:49 AM

Post #5 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed, Jun 27, 2012 at 2:37 PM, Rafael Garcia-Suarez <rgs [at] consttype> wrote:
> On 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-comment [at] perl> wrote:
>> Alternately, you can continue using given/when and refer to $::_ in your first block, rather than
>> $_.
>
> C<our $_> should work, too.
>
>> I suggest ditching given/when, though.
>
> Or fix the internal macro that gives access to $_ from XS.

There is UNDERBAR, but it does make code more complicated because it
can't be localized. We need something smarter than that.

Leon

perlbug-followup at perl

Jun 27, 2012, 8:18 AM

Post #6 of 43 (284 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed Jun 27 05:37:31 2012, rgs [at] consttype wrote:
> On 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-
> comment [at] perl> wrote:
> > Alternately, you can continue using given/when and refer to $::_ in
> your first block, rather than
> > $_.
>
> C<our $_> should work, too.
>
> > I suggest ditching given/when, though.
>
> Or fix the internal macro that gives access to $_ from XS.

Or just make given localise $'_, as everybody expects it to.

Or just deprecate given/when outright.

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

perl.p5p at rjbs

Jun 27, 2012, 10:53 AM

Post #7 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

* Father Chrysostomos via RT <perlbug-followup [at] perl> [2012-06-27T11:18:15]
> Or just make given localise $'_, as everybody expects it to.
>
> Or just deprecate given/when outright.

You are on my shoulder, whispering, but are you an angel or a devil?

--
rjbs

Attachments:

signature.asc (0.48 KB)

aaron at priven

Jun 27, 2012, 12:07 PM

Post #8 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed, Jun 27, 2012 at 8:18 AM, Father Chrysostomos via RT <
perlbug-followup [at] perl> wrote:

> On Wed Jun 27 05:37:31 2012, rgs [at] consttype wrote:
> > On 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-
> > comment [at] perl> wrote:
> > > Alternately, you can continue using given/when and refer to $::_ in
> > your first block, rather than
> > > $_.
> >
> > C<our $_> should work, too.
> >
> > > I suggest ditching given/when, though.
> >
> > Or fix the internal macro that gives access to $_ from XS.
>
> Or just make given localise $'_, as everybody expects it to.
>
> Or just deprecate given/when outright.
>
>
given isn't, of course, the only way to make a lexical $_ -- a simple "my
$_" works as well.

And lexical $_ has other problems -- for example I wrote here why the
niftiness of Text::Trim doesn't work with lexical $_, even with the
underscore prototype:

http://perlmonks.org/?node_id=958820

--
Aaron Priven, aaron [at] priven

perlbug-comment at perl

Jun 27, 2012, 12:32 PM

Post #9 of 43 (284 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed Jun 27 10:53:54 2012, perl.p5p [at] rjbs wrote:
> * Father Chrysostomos via RT <perlbug-followup [at] perl> [2012-06-
> 27T11:18:15]
> > Or just make given localise $'_, as everybody expects it to.
> >
> > Or just deprecate given/when outright.
>
> You are on my shoulder, whispering, but are you an angel or a devil?

:-) That was enough to make me laugh out loud.

--

Father Chrysostomos

rgs at consttype

Jun 27, 2012, 3:03 PM

Post #10 of 43 (288 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On 27 June 2012 21:07, Aaron Priven <aaron [at] priven> wrote:
>
> And lexical $_ has other problems -- for example I wrote here why the
> niftiness of Text::Trim doesn't work with lexical $_, even with the
> underscore prototype:
>
> http://perlmonks.org/?node_id=958820

To me that's more a prototype problem than an lexical $_ problem.

The purpose of lexical $_ is to hide $_ from other scopes, in
particular other functions. The _ prototype was added to allow to
specify a default to $_, lexical or not.

Now what we want is to mimic builtins that can access the current $_.
The traditional way of mimicing builtins was to use prototypes, which
are, as we know, a less than perfect solution. On the other hand one
could argue that since you've declared $_ explicitly lexical, for
maintainability purposes we shouldn't provide ways around that -- the
old "enough rope to shoot you in the foot" balance.

My current opinion (since a couple of years actually) is that
lexicalisation of $_ should *always* be explicit. That means that
given should either go, or stop lexicalising $_ (and localise it
instead, or whatever word is used to describe what foreach does to
it.)

perl.p5p at rjbs

Jun 27, 2012, 5:12 PM

Post #11 of 43 (287 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

* Rafael Garcia-Suarez <rgs [at] consttype> [2012-06-27T18:03:16]
> My current opinion (since a couple of years actually) is that
> lexicalisation of $_ should *always* be explicit. That means that
> given should either go, or stop lexicalising $_ (and localise it
> instead, or whatever word is used to describe what foreach does to
> it.)

Mine also, for some time now. A lexical $_ is fine, but one should get it
because one asked for it and understands what one is getting into.

"Nobody" writes "my $_" without thinking about it, because it's a weird thing
to write. "given" sneaks the lexicalization in there.

I wonder how much code would break were given to stop lexicalizing. Even
though it is, in theory, quite a significant change, my feeling is "basically
none, except toys meant to show off the lexical ARG." Maybe we should smoke
CPAN.

--
rjbs

Attachments:

signature.asc (0.48 KB)

aaron at priven

Jun 27, 2012, 5:29 PM

Post #12 of 43 (283 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed, Jun 27, 2012 at 3:03 PM, Rafael Garcia-Suarez <rgs [at] consttype>
wrote:

> To me that's more a prototype problem than an lexical $_ problem.
>

I'm not sure what difference it makes to call it a prototype problem. I
suppose a new prototype that says "If there's nothing in @_, put an alias
to the current $_ in it, but otherwise leave @_ alone" could solve the
specific issue I identified with Text::Trim and similar code, but it seems
like a very special case and certainly doesn't solve the issue that

my $_;
grep { $_ eq 'fred'} @list;

works while

my $_;
use List::Util;
List::Util::first {$_ eq 'fred'} @list;

does not (at least in pure perl).

On Wed, Jun 27, 2012 at 5:12 PM, Ricardo Signes
<perl.p5p [at] rjbs>wrote:

> "Nobody" writes "my $_" without thinking about it, because it's a weird
> thing
> to write.
>

I disagree. It is weird only because you are familiar with the usual "local
$_" convention. Perl programmers with less specific knowledge of the flaws
of lexical $_ are all too likely to treat $_ like any other variable they
might want to use.

--
Aaron Priven, aaron [at] priven

perlbug-followup at perl

Jun 27, 2012, 6:19 PM

Post #13 of 43 (284 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed Jun 27 17:13:21 2012, perl.p5p [at] rjbs wrote:
> I wonder how much code would break were given to stop lexicalizing.
> Even
> though it is, in theory, quite a significant change, my feeling is
> "basically
> none, except toys meant to show off the lexical ARG." Maybe we should
> smoke
> CPAN.

Steffen Müller, could you run a smoke against sprout/givendefsv?

With that branch, I get this (compared with 5.16.0):

$ perl5.16.0 -le 'use 5.01; given (23) { foo() } sub foo { when(23) {
print "ok" } default { print "not ok" } }'
not ok
$ ./perl -le 'use 5.01; given (23) { foo() } sub foo { when(23) { print
"ok" } default { print "not ok" } }'
ok

$ perl5.16.0 -le 'use 5.01; given ($x) { $_ = 3; foo() } sub foo { print
$x }'

$ ./perl -le 'use 5.01; given ($x) { $_ = 3; foo() } sub foo { print $x }'
3

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

perlbug-followup at perl

Jun 27, 2012, 8:45 PM

Post #14 of 43 (284 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed Jun 27 18:19:21 2012, sprout wrote:
> On Wed Jun 27 17:13:21 2012, perl.p5p [at] rjbs wrote:
> > I wonder how much code would break were given to stop lexicalizing.
> > Even
> > though it is, in theory, quite a significant change, my feeling is
> > "basically
> > none, except toys meant to show off the lexical ARG." Maybe we should
> > smoke
> > CPAN.
>
> Steffen M�ller, could you run a smoke against sprout/givendefsv?

Oh dear. RT’s Unicode bug strikes again.

If you have already started with 874b0bd15 (the original head), please
stop the smokers and restart them with 23e5f9d66b.

Ten cubes! :-)

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

mail at steffen-mueller

Jun 27, 2012, 10:29 PM

Post #15 of 43 (283 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On 06/28/2012 05:45 AM, Father Chrysostomos via RT wrote:
> On Wed Jun 27 18:19:21 2012, sprout wrote:
>> On Wed Jun 27 17:13:21 2012, perl.p5p [at] rjbs wrote:
>>> I wonder how much code would break were given to stop lexicalizing.
>>> Even
>>> though it is, in theory, quite a significant change, my feeling is
>>> "basically
>>> none, except toys meant to show off the lexical ARG." Maybe we should
>>> smoke
>>> CPAN.
>>
>> Steffen M�ller, could you run a smoke against sprout/givendefsv?
>
> Oh dear. RT’s Unicode bug strikes again.
>
> If you have already started with 874b0bd15 (the original head), please
> stop the smokers and restart them with 23e5f9d66b.

Currently running a smoke of Chip's chip/magicflags6 branch.

Progress at:
http://users.perl5.git.perl.org/~tsee/progress.html

When that's done, I'd be glad to smoke this for you. Alternatively,
since you are a committer, you can also use the infrastructure yourself.
Either way: care to remind me in a couple of days if I drop it?

Cheers,
Steffen

jvromans at squirrel

Jun 27, 2012, 11:13 PM

Post #16 of 43 (283 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

Ricardo Signes <perl.p5p [at] rjbs> writes:

> I wonder how much code would break were given to stop lexicalizing.

I don't expect much code to break, given that I don't think given/when
is already used much. Compatibility with older perl versions, no added
benefits, much confusion, and so on.

If we are going to deprecate given/when, we shouldn't wait much longer.

-- Johan

perlbug-followup at perl

Jun 27, 2012, 11:19 PM

Post #17 of 43 (284 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Wed Jun 27 23:13:44 2012, jv wrote:
> Ricardo Signes <perl.p5p [at] rjbs> writes:
>
> > I wonder how much code would break were given to stop lexicalizing.
>
> I don't expect much code to break, given that I don't think given/when
> is already used much. Compatibility with older perl versions, no added
> benefits, much confusion, and so on.
>
> If we are going to deprecate given/when, we shouldn't wait much longer.

+27.93

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

rs at 474

Jun 28, 2012, 6:21 AM

Post #18 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu, 2012-06-28 at 08:13 +0200, Johan Vromans wrote:
> Ricardo Signes <perl.p5p [at] rjbs> writes:
>
> > I wonder how much code would break were given to stop lexicalizing.
>
> I don't expect much code to break, given that I don't think given/when
> is already used much. Compatibility with older perl versions, no added
> benefits, much confusion, and so on.
>
> If we are going to deprecate given/when, we shouldn't wait much longer.

Might it not make more sense to change the $_ it populates to a
localized instead of a lexical one? That seems to be the part that
confuses people. The other is the smartmatch operator. And removing
given/when will do nothing there.

regards,
Robert

dmcbride at cpan

Jun 28, 2012, 6:53 AM

Post #19 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thursday June 28 2012 3:21:32 PM Robert Sedlacek wrote:
> On Thu, 2012-06-28 at 08:13 +0200, Johan Vromans wrote:
> > Ricardo Signes <perl.p5p [at] rjbs> writes:
> > > I wonder how much code would break were given to stop lexicalizing.
> >
> > I don't expect much code to break, given that I don't think given/when
> > is already used much. Compatibility with older perl versions, no added
> > benefits, much confusion, and so on.
> >
> > If we are going to deprecate given/when, we shouldn't wait much longer.
>
> Might it not make more sense to change the $_ it populates to a
> localized instead of a lexical one? That seems to be the part that
> confuses people. The other is the smartmatch operator. And removing
> given/when will do nothing there.

This is what I would like to see as well. The whole given/when thing may not
be in wide use on CPAN where many authors strive to be backward-compatible
with 5.8.8. But that may not be indicative of the adoption of the feature.

At $work, I already had to convince another team to drop their "use Switch"
statements, and the code relying on it, due to its fragility. They are likely
using given/when in the new code targetting AIX 7 (where perl 5.10.1 is
deployed).

Anyone coming from a C or shell background is going to be used to this idea,
even if not exactly the same construct, and perl's lack of switch statement
has long been a sticking point. Getting rid of the one we have now seems ill-
advised.

Instead, if the real problems with given/when are a) lexical $_ and b)
smartmatch, and (b) is not really fixable, why not fix (a)? Besides, (a) is the
part directly dealing with this defect.

Going back to lexical $_ should only be done when we can find a way to get it
to DWIM properly. And, given its history, I'm not sure that's possible, at
least not in a way that the cure isn't worse than the disease.

tl;dr - I agree with Robert :-) Please don't remove given/when when the fix to
the larger problem (at least from my perspective) seems so conceptually
straightforward.

Attachments:

signature.asc (0.19 KB)

perlbug-followup at perl

Jun 28, 2012, 8:24 AM

Post #20 of 43 (283 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu Jun 28 06:53:40 2012, dmcbride [at] cpan wrote:
> Anyone coming from a C or shell background is going to be used to this
> idea,
> even if not exactly the same construct, and perl's lack of switch
> statement
> has long been a sticking point.

We have always had for/last.

> Getting rid of the one we have now
> seems ill-
> advised.

We don’t have to get rid of it to deprecate it. Just stop ‘use 5.18’
from enabling it. People can still get it with ‘use 5.16’ or CORE::given.

> Instead, if the real problems with given/when are a) lexical $_ and b)
> smartmatch, and (b) is not really fixable, why not fix (a)? Besides,
> (a) is the
> part directly dealing with this defect.

But there is also the icky scoping of when and break, and how they
interact when it comes to nested sub calls, some having for(), some
given(), etc. Sometimes you get errors that are just wrong.

Also, when’s algorithm for guessing when you want implicit smartmatch is
completely broken. Even the examples in the docs of how it ‘usually
does what you want’ don’t work as expected and have bizarre results.

Oh, and let’s deprecate smartmatch while we are at it. :-) Despite the
smiley, I’m actually serious. Every time some makes a proposal
simplifying smartmatch to make it predictable, someone else points out
that the ‘main’ use for smartmatch is not included. Nobody can agree on
what its ‘main’ purpose is. Again, deprecation does not mean removal.

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

rs at 474

Jun 28, 2012, 9:17 AM

Post #21 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
> On Thu Jun 28 06:53:40 2012, dmcbride [at] cpan wrote:
> > Anyone coming from a C or shell background is going to be used to this
> > idea,
> > even if not exactly the same construct, and perl's lack of switch
> > statement
> > has long been a sticking point.
>
> We have always had for/last.

Which can be quite confusing when it's used for non-looping.

> > Getting rid of the one we have now
> > seems ill-
> > advised.
>
> We don’t have to get rid of it to deprecate it. Just stop ‘use 5.18’
> from enabling it. People can still get it with ‘use 5.16’ or CORE::given.
>
> > Instead, if the real problems with given/when are a) lexical $_ and b)
> > smartmatch, and (b) is not really fixable, why not fix (a)? Besides,
> > (a) is the
> > part directly dealing with this defect.
>
> But there is also the icky scoping of when and break, and how they
> interact when it comes to nested sub calls, some having for(), some
> given(), etc. Sometimes you get errors that are just wrong.
>
> Also, when’s algorithm for guessing when you want implicit smartmatch is
> completely broken. Even the examples in the docs of how it ‘usually
> does what you want’ don’t work as expected and have bizarre results.

Would the first part not be fixable by requiring 'when' to be inside
'given'? Since 'when' breaks out implicitly, it might be too hard to
predict when it's interacting with unknowns. If it always belongs to a
'given' that would work out fine, right?

I can't really comment on the smartmatch detection issues, since I'm not
really up-to-date on them. Is it a problem of specification or
implementation? I assume this behavior is only needed so one can have
auto-breaking conditions that aren't smatch-matches on the same level as
the smart-matching cnoditions? Maybe there is a way to distinguish these
two cases better? Or just always use smart-matching and let CPAN provide
a way to side-step it.

> Oh, and let’s deprecate smartmatch while we are at it. :-) Despite the
> smiley, I’m actually serious. Every time some makes a proposal
> simplifying smartmatch to make it predictable, someone else points out
> that the ‘main’ use for smartmatch is not included. Nobody can agree on
> what its ‘main’ purpose is. Again, deprecation does not mean removal.

How about instead of deprecating it, the undesirable features of it are
deprecated and the rest is left to CPAN? The Smart::Match modules is
actually quite nice and makes for some readable code. A generic,
overloadable comparison operator that isn't (semantically) related to
either string or numerical comparison seems quite useful.

regards,
Robert

perlbug-followup at perl

Jun 28, 2012, 9:38 AM

Post #22 of 43 (283 views)
Permalink

[perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu Jun 28 09:17:43 2012, rs [at] 474 wrote:
> On Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
> > On Thu Jun 28 06:53:40 2012, dmcbride [at] cpan wrote:
> > > Anyone coming from a C or shell background is going to be used to this
> > > idea,
> > > even if not exactly the same construct, and perl's lack of switch
> > > statement
> > > has long been a sticking point.
> >
> > We have always had for/last.
>
> Which can be quite confusing when it's used for non-looping.

I’ve never had that problem. That use of for has been documented (in
perlsyn I think) for a long time.

> > Also, when’s algorithm for guessing when you want implicit smartmatch is
> > completely broken. Even the examples in the docs of how it ‘usually
> > does what you want’ don’t work as expected and have bizarre results.
>
> Would the first part not be fixable by requiring 'when' to be inside
> 'given'? Since 'when' breaks out implicitly, it might be too hard to
> predict when it's interacting with unknowns. If it always belongs to a
> 'given' that would work out fine, right?

when can break out of for. We also have to take given(1){foo()} sub
foo{ when(1){} } into account.

>
> I can't really comment on the smartmatch detection issues, since I'm not
> really up-to-date on them. Is it a problem of specification or
> implementation? I assume this behavior is only needed so one can have
> auto-breaking conditions that aren't smatch-matches on the same level as
> the smart-matching cnoditions? Maybe there is a way to distinguish these
> two cases better?

That’s why it’s needed. But it doesn’t work well at all. It goes
searching recursively through branches of || and && trying to
second-guess what the programmer wants, but then it applies smartmatch,
not to the inner expressions, but to the whole thing.

> Or just always use smart-matching and let CPAN provide
> a way to side-step it.
>
> > Oh, and let’s deprecate smartmatch while we are at it. :-) Despite the
> > smiley, I’m actually serious. Every time some makes a proposal
> > simplifying smartmatch to make it predictable, someone else points out
> > that the ‘main’ use for smartmatch is not included. Nobody can agree on
> > what its ‘main’ purpose is. Again, deprecation does not mean removal.
>
> How about instead of deprecating it, the undesirable features of it are
> deprecated and the rest is left to CPAN? The Smart::Match modules is
> actually quite nice and makes for some readable code. A generic,
> overloadable comparison operator that isn't (semantically) related to
> either string or numerical comparison seems quite useful.

So it’s a generic ‘do something funny with this object’ operator? Do
you mean the rhs has to be an object with smartmatch overloading, and
everything else is deprecated?

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818

doy at tozt

Jun 28, 2012, 9:49 AM

Post #23 of 43 (284 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu, Jun 28, 2012 at 09:38:45AM -0700, Father Chrysostomos via RT wrote:
> > How about instead of deprecating it, the undesirable features of it are
> > deprecated and the rest is left to CPAN? The Smart::Match modules is
> > actually quite nice and makes for some readable code. A generic,
> > overloadable comparison operator that isn't (semantically) related to
> > either string or numerical comparison seems quite useful.
>
> So it’s a generic ‘do something funny with this object’ operator? Do
> you mean the rhs has to be an object with smartmatch overloading, and
> everything else is deprecated?

That is pretty close to what rjbs proposed last year.

-doy

rs at 474

Jun 28, 2012, 10:08 AM

Post #24 of 43 (283 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu, 2012-06-28 at 09:38 -0700, Father Chrysostomos via RT wrote:
> On Thu Jun 28 09:17:43 2012, rs [at] 474 wrote:
> > On Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
> > > On Thu Jun 28 06:53:40 2012, dmcbride [at] cpan wrote:
> > > > Anyone coming from a C or shell background is going to be used to this
> > > > idea,
> > > > even if not exactly the same construct, and perl's lack of switch
> > > > statement
> > > > has long been a sticking point.
> > >
> > > We have always had for/last.
> >
> > Which can be quite confusing when it's used for non-looping.
>
> I’ve never had that problem. That use of for has been documented (in
> perlsyn I think) for a long time.

True, and yet, when I see 'for' I think 'loop' :) The only exception is
simple postfix for operations like

s{$}{.pm}, s{::}{/} for @packages;

> > > Also, when’s algorithm for guessing when you want implicit smartmatch is
> > > completely broken. Even the examples in the docs of how it ‘usually
> > > does what you want’ don’t work as expected and have bizarre results.
> >
> > Would the first part not be fixable by requiring 'when' to be inside
> > 'given'? Since 'when' breaks out implicitly, it might be too hard to
> > predict when it's interacting with unknowns. If it always belongs to a
> > 'given' that would work out fine, right?
>
> when can break out of for. We also have to take given(1){foo()} sub
> foo{ when(1){} } into account.

I know that it does that now. I'm proposing that it doesn't. Since a
switch/case is a real advantage, I'm just thinking if there are ways
between "deal with the issues" and "full deprecation".

> > I can't really comment on the smartmatch detection issues, since I'm not
> > really up-to-date on them. Is it a problem of specification or
> > implementation? I assume this behavior is only needed so one can have
> > auto-breaking conditions that aren't smatch-matches on the same level as
> > the smart-matching cnoditions? Maybe there is a way to distinguish these
> > two cases better?
>
> That’s why it’s needed. But it doesn’t work well at all. It goes
> searching recursively through branches of || and && trying to
> second-guess what the programmer wants, but then it applies smartmatch,
> not to the inner expressions, but to the whole thing.

Maybe it shouldn't do *that* then? :) Forcing people to use 'if' and an
actual 'break' when they don't want to smart match against the given
topic might be less nice, but it still might lead to less surprising
results. Plus, since smartmatching can be customized, CPAN (or maybe a
even a simple sub one writes oneself) could provide a

when (nontopical { $x == $y && $z eq 23 }) {
# ...
}

which simply ignores the passed topic and evaluates the expression by
itself.

> > Or just always use smart-matching and let CPAN provide
> > a way to side-step it.
> >
> > > Oh, and let’s deprecate smartmatch while we are at it. :-) Despite the
> > > smiley, I’m actually serious. Every time some makes a proposal
> > > simplifying smartmatch to make it predictable, someone else points out
> > > that the ‘main’ use for smartmatch is not included. Nobody can agree on
> > > what its ‘main’ purpose is. Again, deprecation does not mean removal.
> >
> > How about instead of deprecating it, the undesirable features of it are
> > deprecated and the rest is left to CPAN? The Smart::Match modules is
> > actually quite nice and makes for some readable code. A generic,
> > overloadable comparison operator that isn't (semantically) related to
> > either string or numerical comparison seems quite useful.
>
> So it’s a generic ‘do something funny with this object’ operator? Do
> you mean the rhs has to be an object with smartmatch overloading, and
> everything else is deprecated?

Well, not a "do something funny" but "a complex match".

But in general yeah, I'm just not sure about deprecating "everything".
The 'undef' case for example seems useful. Same with the regexp matching
and code references I think. It only starts to get hard to keep in your
head when containers are involved. Does it match hash keys or values,
does it check if any or all are matching? But then again, since they now
do deep matches depending on the container, it's hard to simply re-use
them instead of just using objects.

Anyway, these things might be more maintainable in the long run if they
were more explicit. Either by explicitly enabling behavior with a
lexical pragma, or by using something that returns an overloaded object.
(No idea if the first one is possible).

regards,
Robert

doy at tozt

Jun 28, 2012, 10:23 AM

Post #25 of 43 (288 views)
Permalink

Re: [perl #113818] List::Util::first() don't work into when() context [In reply to]

On Thu, Jun 28, 2012 at 07:08:50PM +0200, Robert Sedlacek wrote:
> > So it’s a generic ‘do something funny with this object’ operator? Do
> > you mean the rhs has to be an object with smartmatch overloading, and
> > everything else is deprecated?
>
> Well, not a "do something funny" but "a complex match".
>
> But in general yeah, I'm just not sure about deprecating "everything".
> The 'undef' case for example seems useful. Same with the regexp matching
> and code references I think.

And those were the (only) other cases that rjbs proposed keeping(:

-doy

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads