List::Util::first() don't work into when() context

p5pRT commented 12 years ago

Migrated from rt.perl.org#113818 (status was 'resolved')

Searchable as RT113818$

p5pRT commented 12 years ago

From explorer@joaquinferrero.com

This is a bug report for perl from explorer@joaquinferrero.com\, 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

p5pRT commented 12 years ago

From @b2gills

On Sun\, Jun 24\, 2012 at 1:25 PM\, Joaquin Ferrero \perlbug\-followup@perl\.org 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-archive.perl.org/perl5/Ticket/Display.html?id=113818 >

This is a bug report for perl from explorer@joaquinferrero.com\, 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

p5pRT commented 12 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 12 years ago

From @rjbs

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

I suggest ditching given/when\, though.

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

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

I suggest ditching given/when\, though.

p5pRT commented 12 years ago

@rjbs - Status changed from 'open' to 'resolved'

p5pRT commented 12 years ago

From @rgarcia

On 27 June 2012 13:35\, Ricardo SIGNES via RT \perlbug\-comment@perl\.org 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.

p5pRT commented 12 years ago

From @Leont

On Wed\, Jun 27\, 2012 at 2:37 PM\, Rafael Garcia-Suarez \rgs@consttype\.org wrote:

On 27 June 2012 13:35\, Ricardo SIGNES via RT \perlbug\-comment@perl\.org 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

p5pRT commented 12 years ago

From @cpansprout

On Wed Jun 27 05:37:31 2012\, rgs@consttype.org wrote:

On 27 June 2012 13:35\, Ricardo SIGNES via RT \<perlbug- comment@perl.org> 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

p5pRT commented 12 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@perl\.org [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

p5pRT commented 12 years ago

From aaron@priven.com

On Wed\, Jun 27\, 2012 at 8:18 AM\, Father Chrysostomos via RT \< perlbug-followup@perl.org> wrote:

On Wed Jun 27 05:37:31 2012\, rgs@consttype.org wrote:

On 27 June 2012 13:35\, Ricardo SIGNES via RT \<perlbug- comment@perl.org> 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@priven.com

p5pRT commented 12 years ago

From @cpansprout

On Wed Jun 27 10:53:54 2012\, perl.p5p@rjbs.manxome.org wrote:

* Father Chrysostomos via RT \perlbug\-followup@perl\.org [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

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

On Wed Jun 27 10:53:54 2012\, perl.p5p@rjbs.manxome.org wrote:

* Father Chrysostomos via RT \perlbug\-followup@perl\.org [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

p5pRT commented 12 years ago

From @rgarcia

On 27 June 2012 21:07\, Aaron Priven \aaron@priven\.com 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.)

p5pRT commented 12 years ago

From @rjbs

* Rafael Garcia-Suarez \rgs@consttype\.org [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

p5pRT commented 12 years ago

From aaron@priven.com

On Wed\, Jun 27\, 2012 at 3:03 PM\, Rafael Garcia-Suarez \rgs@consttype\.org 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@rjbs\.manxome\.orgwrote:

"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@priven.com

p5pRT commented 12 years ago

From @cpansprout

On Wed Jun 27 17:13:21 2012\, perl.p5p@rjbs.manxome.org 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

p5pRT commented 12 years ago

From @cpansprout

On Wed Jun 27 18:19:21 2012\, sprout wrote:

On Wed Jun 27 17:13:21 2012\, perl.p5p@rjbs.manxome.org 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

p5pRT commented 12 years ago

From @sciurius

Ricardo Signes \perl\.p5p@rjbs\.manxome\.org 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

p5pRT commented 12 years ago

From @cpansprout

On Wed Jun 27 23:13:44 2012\, jv wrote:

Ricardo Signes \perl\.p5p@rjbs\.manxome\.org 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

p5pRT commented 12 years ago

From @phaylon

On Thu\, 2012-06-28 at 08:13 +0200\, Johan Vromans wrote:

Ricardo Signes \perl\.p5p@rjbs\.manxome\.org 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

p5pRT commented 12 years ago

From @dmcbride

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@rjbs\.manxome\.org 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.

p5pRT commented 12 years ago

From @cpansprout

On Thu Jun 28 06:53:40 2012\, dmcbride@cpan.org 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

p5pRT commented 12 years ago

From @phaylon

On Thu\, 2012-06-28 at 08:24 -0700\, Father Chrysostomos via RT wrote:

On Thu Jun 28 06:53:40 2012\, dmcbride@cpan.org 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

p5pRT commented 12 years ago

From @cpansprout

On Thu Jun 28 09:17:43 2012\, rs@474.at wrote:

On Thu\, 2012-06-28 at 08:24 -0700\, Father Chrysostomos via RT wrote:

On Thu Jun 28 06:53:40 2012\, dmcbride@cpan.org 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

p5pRT commented 12 years ago

From @doy

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

p5pRT commented 12 years ago

From @phaylon

On Thu\, 2012-06-28 at 09:38 -0700\, Father Chrysostomos via RT wrote:

On Thu Jun 28 09:17:43 2012\, rs@474.at wrote:

On Thu\, 2012-06-28 at 08:24 -0700\, Father Chrysostomos via RT wrote:

On Thu Jun 28 06:53:40 2012\, dmcbride@cpan.org 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

p5pRT commented 12 years ago

From @doy

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

p5pRT commented 12 years ago

From @lizmat

On Jun 28\, 2012\, at 6:38 PM\, Father Chrysostomos via RT wrote:

On Thu Jun 28 09:17:43 2012\, rs@474.at wrote:

On Thu\, 2012-06-28 at 08:24 -0700\, Father Chrysostomos via RT wrote:

On Thu Jun 28 06:53:40 2012\, dmcbride@cpan.org 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.

FWIW\, I always use "foreach" for the looping case\, and "for" for the non-looping case. It makes for some sort of sanity.

Liz

p5pRT commented 12 years ago

From @Leont

On Thu\, Jun 28\, 2012 at 6:17 PM\, Robert Sedlacek \rs@474\.at wrote:

On Thu\, 2012-06-28 at 08:24 -0700\, Father Chrysostomos via RT wrote:

On Thu Jun 28 06:53:40 2012\, dmcbride@cpan.org 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 agree\, it's ugly.

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?

That would completely break my uses of it. I'm not interested in a when that does that.

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.

It's awful. In Smart::Match\, I actually had to overload not just smartmatching\, but also boolean conversion to do smartmatch\, because depending on the function having arguments or not it can trigger boolean instead of smartmatching behavior. It required an XS hack to get the lexical $_ right :-(.

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.

I agree.

Leon

p5pRT commented 12 years ago

From @tsee

On 06/28/2012 03:19 AM\, Father Chrysostomos via RT wrote:

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

Running. Look for progress at

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

and for output at

http://users.perl5.git.perl.org/~tsee/givendefsv/ and http://users.perl5.git.perl.org/~tsee/givendefsv_withmissing_dists/

--Steffen

p5pRT commented 12 years ago

From mail@steffen-mueller.net

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@rjbs.manxome.org 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

p5pRT commented 12 years ago

From @chipdude

On 6/28/2012 9:49 AM\, Jesse Luehrs wrote:

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.

Once my magic flags patch is accepted\, we can make string and number and boolean smart matching REALLY WORK. So let's not throw the baby out with the bathwater\, at least until we verify that isn't a real baby.

p5pRT commented 12 years ago

From @cpansprout

On Thu Jun 28 23:03:02 2012\, smueller@cpan.org wrote:

On 06/28/2012 03:19 AM\, Father Chrysostomos via RT wrote:

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

Running. Look for progress at

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

and for output at

http://users.perl5.git.perl.org/~tsee/givendefsv/ and http://users.perl5.git.perl.org/~tsee/givendefsv_withmissing_dists/

Thank you.

The only new failures are due to timing or network issues.

I think we can safely make given alias $_ the way for does.

--

Father Chrysostomos

p5pRT commented 12 years ago

From @ap

* Reverend Chip \rev\.chip@gmail\.com [2012-06-30 01:50]:

On 6/28/2012 9:49 AM\, Jesse Luehrs wrote:

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.

Once my magic flags patch is accepted\, we can make string and number and boolean smart matching REALLY WORK. So let's not throw the baby out with the bathwater\, at least until we verify that isn't a real baby.

No\, not in fact. It makes it almost certain to work for values that came from the source code but all data coming in from I/O\, number or not\, will be marked as a string\, and explicit care will have to be taken to type-coerce it to a number or boolean even under your patch. Admittedly the patch will make it possible to do that at all. But the fundamental nature of Perl 5 as a language with polymorphic values (which therefore needs to have monomorphic operators) will not change\, and smartmatch as a polymorphic operator by design cannot suddenly cease being inherently in opposition to that nature.

It will work much better\, but it cannot work right.

(It may not need to work right if it is close enough. I am sceptical and will be quite unsurprised if it turns out to have to\, but my mind is not made up.)

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 12 years ago

From @chipdude

On Wed\, Jul 11\, 2012 at 07:27:35AM +0200\, Aristotle Pagaltzis wrote:

Reverend Chip \rev\.chip@gmail\.com [2012-06-30 01:50]:

Once my magic flags patch is accepted\, we can make string and number and boolean smart matching REALLY WORK. So let's not throw the baby out with the bathwater\, at least until we verify that isn't a real baby.

No\, not in fact. It makes it almost certain to work for values that came from the source code but all data coming in from I/O\, number or not\, will be marked as a string\, and explicit care will have to be taken to type-coerce it to a number or boolean even under your patch.

Well\, that's a fair cop. I wonder\, though...

WARNING - WILD ASS GUESSING AHEAD

... if my patch's ability to correctly discern the RIGHT operand type might save things. What if\, e.g.

$a ~~ 42

would be true if $a="42"\, while being false and not warning if $a="foo"? (Using looks_like_number() as a fallback\, you see.) This whole approach only becomes practical once we can be sure that the 42 is really 42\, which is where my patch helps. -- Chip Salzenberg

p5pRT commented 12 years ago

From @ap

* Rev. Chip \rev\.chip@gmail\.com [2012-07-11 09:35]:

What if\, e.g.

$a ~~ 42

would be true if $a="42"\, while being false and not warning if $a="foo"? (Using looks_like_number() as a fallback\, you see.) This whole approach only becomes practical once we can be sure that the 42 is really 42\, which is where my patch helps.

Part of me is feeling queasy; part of me is thinking this might just work. I don’t think I will know which is the right intuition before I can give it a try in anger.

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 12 years ago

From @b2gills

On Wed\, Jul 11\, 2012 at 2:29 AM\, Rev. Chip \rev\.chip@gmail\.com wrote:

On Wed\, Jul 11\, 2012 at 07:27:35AM +0200\, Aristotle Pagaltzis wrote:

Reverend Chip \rev\.chip@gmail\.com [2012-06-30 01:50]:

Once my magic flags patch is accepted\, we can make string and number and boolean smart matching REALLY WORK. So let's not throw the baby out with the bathwater\, at least until we verify that isn't a real baby.

No\, not in fact. It makes it almost certain to work for values that came from the source code but all data coming in from I/O\, number or not\, will be marked as a string\, and explicit care will have to be taken to type-coerce it to a number or boolean even under your patch.

Well\, that's a fair cop. I wonder\, though...

WARNING - WILD ASS GUESSING AHEAD

... if my patch's ability to correctly discern the RIGHT operand type might save things. What if\, e.g.

$a ~~ 42

would be true if $a="42"\, while being false and not warning if $a="foo"? (Using looks_like_number() as a fallback\, you see.) This whole approach only becomes practical once we can be sure that the 42 is really 42\, which is where my patch helps. -- Chip Salzenberg

Am I right to assume that

perl -E'$a = 42; $b = "$a text"; say $b ~~ $a ? 1 : 0' perl -E'$a = "42"; $b = "$a text"; say $b ~~ $a ? 1 : 0' perl -E'$a = 42; $b = "$a text"; $c = 0+$b; say $b ~~ $a ? 1 : 0' # \<- this one is pointless perl -E'$a = "42"; $b = "$a text"; $c = 0+$a; say $b ~~ $a ? 1 : 0'

will print out:

1 0 1 0

instead of:

1 0 1 1

as it does now

p5pRT commented 12 years ago

From @chipdude

On 7/11/2012 8:33 AM\, Brad Gilbert wrote:

On Wed\, Jul 11\, 2012 at 2:29 AM\, Rev. Chip \rev\.chip@gmail\.com wrote:

On Wed\, Jul 11\, 2012 at 07:27:35AM +0200\, Aristotle Pagaltzis wrote:

Reverend Chip \rev\.chip@gmail\.com [2012-06-30 01:50]:

Once my magic flags patch is accepted\, we can make string and number and boolean smart matching REALLY WORK. So let's not throw the baby out with the bathwater\, at least until we verify that isn't a real baby. No\, not in fact. It makes it almost certain to work for values that came from the source code but all data coming in from I/O\, number or not\, will be marked as a string\, and explicit care will have to be taken to type-coerce it to a number or boolean even under your patch. Well\, that's a fair cop. I wonder\, though...

WARNING - WILD ASS GUESSING AHEAD

... if my patch's ability to correctly discern the RIGHT operand type might save things. What if\, e.g.

$a ~~ 42

would be true if $a="42"\, while being false and not warning if $a="foo"? (Using looks_like_number() as a fallback\, you see.) This whole approach only becomes practical once we can be sure that the 42 is really 42\, which is where my patch helps. -- Chip Salzenberg Am I right to assume that
perl \-E'$a = 42; $b = "$a text"; say $b ~~ $a ? 1 : 0'
perl \-E'$a = "42"; $b = "$a text"; say $b ~~ $a ? 1 : 0'
perl \-E'$a = 42; $b = "$a text"; $c = 0\+$b; say $b ~~ $a ? 1 : 0'
# \<- this one is pointless perl -E'$a = "42"; $b = "$a text"; $c = 0+$a; say $b ~~ $a ? 1 : 0'

will print out:
1
0
1
0
instead of:
1
0
1
1
as it does now

In short\, yes. The first example breaks down to "42 text" ~~ 42. I am not sure but I think this should succeed as it does. (Whether it warns is a separate question. I think it should. I think.) The second example is two different strings\, so it fails as it should. The third and fourth examples just add doing math on a string\, and the point of my scalar types patch is to ensure that has (almost) no visible effects.

p5pRT commented 12 years ago

From @cpansprout

On Fri Jun 29 16:46:56 2012\, rev.chip@gmail.com wrote:

On 6/28/2012 9:49 AM\, Jesse Luehrs wrote:

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.

Once my magic flags patch is accepted\, we can make string and number and boolean smart matching REALLY WORK. So let's not throw the baby out with the bathwater\, at least until we verify that isn't a real baby.

Which part of the baby? Your patch\, if I remember\, exposed the stringiness or numericity as an API\, which I think is a bad idea; not for technical reasons\, but because it is too much of a cultural shift. Have you ever written a bridge between two programming languages\, one of which is Perl? I have. Overloaded objects proved extremely useful. But then I found myself having to apply workarounds all over the place for code that does different things based on whether an argument is a reference. If we start allowing code to say if(is_string($arg)){...} then this will open up a can of worms. We will just end up with more CPAN modules that don’t ‘do things right’\, partly because ‘right’ has been redefined in some peoples’ minds. String overloading will become even less usable. There is also the problem that all dumping modules will become officially buggy overnight.

Traditionally Perl has had typed operators and (mostly) typeless values\, the few warts notwithstanding. And I believe those warts really are warts. I have been working on fixing those that I can over time. I think if we design any new interfaces that treat 3 and "3" differently\, or codify any existing interfaces that do so\, we will be taking a step in the wrong direction.

--

Father Chrysostomos

p5pRT commented 12 years ago

From @chipdude

On Wed\, Jul 11\, 2012 at 12:38:41PM -0700\, Father Chrysostomos via RT wrote:

Which part of the baby? Your patch\, if I remember\, exposed the stringiness or numericity as an API [...]

Yes\, insofar as conversions no longer lose track of the original type.

which I think is a bad idea; not for technical reasons\, but because it is too much of a cultural shift.

Can't agree. Culture is subjective and interactive; we both form it and are formed by it. And we interact with the outside world\, some of which has very strong opinions on strings vs. numbers. Ever ask Larry if he wishes he'd made a boolean type? I think he would\, and we'd all be better off.

If we start allowing code to say if(is_string($arg)){...} then this will open up a can of worms. We will just end up with more CPAN modules that don’t ‘do things right’\, partly because ‘right’ has been redefined in some peoples’ minds.

I can't undererstand this argument. It's not that I disagree with it\, I don't understand what the argument *is*. Could you please be more specific? Beware of being persuasive with a slippery slope argument\, too.

There is also the problem that all dumping modules will become officially buggy overnight.

Now I know you're missing the point. Dumping modules already distinguish numbers from strings. -- Chip Salzenberg

p5pRT commented 12 years ago

From @ap

* Rev. Chip \rev\.chip@gmail\.com [2012-07-12 00:35]:

On Wed\, Jul 11\, 2012 at 12:38:41PM -0700\, Father Chrysostomos via RT wrote:

Which part of the baby? Your patch\, if I remember\, exposed the stringiness or numericity as an API [...]

Yes\, insofar as conversions no longer lose track of the original type.

which I think is a bad idea; not for technical reasons\, but because it is too much of a cultural shift.

Can't agree. Culture is subjective and interactive; we both form it and are formed by it. And we interact with the outside world\, some of which has very strong opinions on strings vs. numbers. Ever ask Larry if he wishes he'd made a boolean type? I think he would\, and we'd all be better off.

This is a nonsensical statement. If it were true on the face of it then the smartmatch operator would not be causing the problems that it does. The problem is that a language is a whole. You cannot change parts of to work in ways that do not harmonise with other parts and expect the whole to continue to fit together equally well. A successful ”cultural shift” of the sort you postulate would in truth require razing most of the language and doing over the entire design starting from key decisions about the data model. (I believe if you did a good job with it based on the premises implied\, you would be led to a design much alike Python in its data model and set of operators. That is not a bad thing per se but I would have less interest in the result than I do in Perl as she is.)

If we start allowing code to say if(is_string($arg)){...} then this will open up a can of worms. We will just end up with more CPAN modules that don’t ‘do things right’\, partly because ‘right’ has been redefined in some peoples’ minds.

Two responses\, FC:

1. In most cases such code will be as buggy as code that tries to look at the UTF8 flag now. I believe the response should then be the same as it is now to people who write code that looks at the UTF8 flag: “stop that”.

2. It does not make a good argument against the patch because people *already* try to write such code with such as `looks_like_number`; this patch would at least allow such code to work better in those cases where that is motivated by a legitimate desire\, of which cases there are a few (most prominently to my mind\, JSON de-/serialisers).

Ultimately I believe Chip’s patch really makes no serious difference to the language\, but will alleviates some of the pain when having to do things in Perl that cut against its grain to some extent. That seems desirable.

I can't undererstand this argument. It's not that I disagree with it\, I don't understand what the argument *is*. Could you please be more specific? Beware of being persuasive with a slippery slope argument\, too.

I think the issue with his argument is that you overestimate the impact of your patch on the semantics of the language\, or at least you present it in language that so overestimates it. And after unwittingly following you into that ditch\, FC is noticing and complaining that down there is not a good place to be. In a manner of speaking the slope is yours and the slip is his. :-)

There is also the problem that all dumping modules will become officially buggy overnight.

Now I know you're missing the point. Dumping modules already distinguish numbers from strings.

And the reason it isn’t causing problems is that no one is relying on that distinction in any deep way\, as well they still shouldn’t even once your patch is in place. He who starts to will find that problems follow.

Essentially your patch\, to me\, boils down to more reliable serialisation for formats with a data model pickier than Perl’s\, as well as fewer bugs in the bitwise operators (which really means those operators should be redesigned and the old design removed with prejudice; unfortunately that is a lot less realistic than it is for smartmatch)\, and suchlike polish.

Therefore I like it.

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 12 years ago

From @chipdude

On Thu\, Jul 12\, 2012 at 11:35:42AM +0200\, Aristotle Pagaltzis wrote:

Ultimately I believe Chip’s patch really makes no serious difference to the language\, but will alleviates some of the pain when having to do things in Perl that cut against its grain to some extent. That seems desirable.

That's fair. I like Perl's pre-smartmatch operators fine. I only intend to reduce the pain of coping with the boundary between Perl's historical contextual typing (where operator context controls\, and data follows by conversion) and intrinsic typing (where types are inherent to data\, and operators follow along). That boundary already lay inside the borders of Perl due to the bitwise operators.

Smart match is a separate issue. If people want smart match they'll have it\, whether or not original types can be reliably found (which is all my patch offers). If they don't want it\, the patch won't change that either.

Beware of being persuasive with a slippery slope argument\, too.

I think the issue with his argument is that you overestimate the impact of your patch on the semantics of the language\, or at least you present it in language that so overestimates it. And after unwittingly following you into that ditch\, FC is noticing and complaining that down there is not a good place to be. In a manner of speaking the slope is yours and the slip is his. :-)

You're making more sense than I was. So: OK. Father C: ^^ -- Chip Salzenberg

p5pRT commented 12 years ago

From @cpansprout

On Thu Jul 12 02:36:51 2012\, aristotle wrote:

* Rev. Chip \rev\.chip@gmail\.com [2012-07-12 00:35]:

On Wed\, Jul 11\, 2012 at 12:38:41PM -0700\, Father Chrysostomos via RT wrote:

If we start allowing code to say if(is_string($arg)){...} then this will open up a can of worms. We will just end up with more CPAN modules that don’t ‘do things right’\, partly because ‘right’ has been redefined in some peoples’ minds.

Two responses\, FC:

1. In most cases such code will be as buggy as code that tries to look at the UTF8 flag now.

That’s exactly what I’m afraid of.

I believe the response should then be the same as it is now to people who write code that looks at the UTF8 flag: “stop that”.

But that will be hard to back in the face of this ‘new feature’.

2. It does not make a good argument against the patch because people *already* try to write such code with such as `looks_like_number`;

Actually\, there is nothing wrong with looks_like_number\, as code using it will treat 3 and "3" the same way. In fact\, Perl’s unary negation uses it. Any string beginning with [a-zA-Z]\, or any string that begins with '-' and !looks_like_number gets string negation. Anything else gets numeric negation. (Or at least that’s how it is in bleadperl\, now that I’ve fixed the inconsistencies.)

this patch would at least allow such code to work better in those cases where that is motivated by a legitimate desire\,

I still think looks_like_number is a better approach in most cases.

of which cases there are a few (most prominently to my mind\, JSON de- /serialisers).

Ultimately I believe Chip’s patch really makes no serious difference to the language\, but will alleviates some of the pain when having to do things in Perl that cut against its grain to some extent. That seems desirable.

I can't undererstand this argument. It's not that I disagree with it\, I don't understand what the argument *is*. Could you please be more specific? Beware of being persuasive with a slippery slope argument\, too.

I think the issue with his argument is that you overestimate the impact of your patch on the semantics of the language\, or at least you present it in language that so overestimates it. And after unwittingly following you into that ditch\, FC is noticing and complaining that down there is not a good place to be. In a manner of speaking the slope is yours and the slip is his. :-)

There is also the problem that all dumping modules will become officially buggy overnight.

Now I know you're missing the point. Dumping modules already distinguish numbers from strings.

And the reason it isn’t causing problems is that no one is relying on that distinction in any deep way\, as well they still shouldn’t even once your patch is in place. He who starts to will find that problems follow.

Essentially your patch\, to me\, boils down to more reliable serialisation for formats with a data model pickier than Perl’s\,

If that is the reason for it\, then I am not opposed\, as long as the documentation for the API makes it clear that using it to treat arguments to functions differently is not its intended use and goes against the spirit of everything Perl 5 stands for.

Let’s not have a repeat of the Unicode bug.

as well as fewer bugs in the bitwise operators (which really means those operators should be redesigned and the old design removed with prejudice; unfortunately that is a lot less realistic than it is for smartmatch)\,

Not at all. Perl 6 has +| and +&\, so why can’t Perl 5? Probably because +~ already means something\, right? ~| is how Perl 6 does stringwise bitwise or. But ~ never means string in Perl 5\, so we would have to come up with something else. Maybe a feature feature could make | ^ stringwise.

and suchlike polish.

Therefore I like it.

Regards\,

--

Father Chrysostomos

p5pRT commented 12 years ago

From @chipdude

On Fri\, Jul 13\, 2012 at 12:15:17AM -0700\, Father Chrysostomos via RT wrote:

On Thu Jul 12 02:36:51 2012\, aristotle wrote:

as well as fewer bugs in the bitwise operators (which really means those operators should be redesigned and the old design removed with prejudice; unfortunately that is a lot less realistic than it is for smartmatch)\,

Not at all.

Sadly\, yes\, some errors^Wodd design decisions are beyond fixing. Say\, the choice of $a[0] vs. @a[0] for example. I think it's clear that how | & ^ work\, fundamentally\, is stuck. All we can do is make them marginally less astonishing. -- Chip Salzenberg

p5pRT commented 12 years ago

From @ap

* Father Chrysostomos via RT \perlbug\-followup@perl\.org [2012-07-13 09:20]:

On Thu Jul 12 02:36:51 2012\, aristotle wrote:

* Rev. Chip \rev\.chip@gmail\.com [2012-07-12 00:35]:

On Wed\, Jul 11\, 2012 at 12:38:41PM -0700\, Father Chrysostomos via RT wrote:

If we start allowing code to say if(is_string($arg)){...} then this will open up a can of worms. We will just end up with more CPAN modules that don’t ‘do things right’\, partly because ‘right’ has been redefined in some peoples’ minds.

Two responses\, FC:

1. In most cases such code will be as buggy as code that tries to look at the UTF8 flag now.

That’s exactly what I’m afraid of.

I believe the response should then be the same as it is now to people who write code that looks at the UTF8 flag: “stop that”.

But that will be hard to back in the face of this ‘new feature’.

I don’t really think so. A big part of the problem with the UTF-8 flag was both the name (should’ve been used UOK) and that it was exposed through “userspace” APIs that easily lead people to trying to rely on it\, as well as documentation that advertised it that way along with lots of code in the core that exhibited the buggy behaviour.

That people would do the wrong thing in the face of such overwhelming instruction to do that is no surprise.

There is no need for the magicflags patch to repeat these mistakes. It need not come with an `is_string` function. If it even did it should be called `has_pvok` or some such\, and any docs should be clear on the limits. But again\, I don’t see a need to supply any API for this. You get strings from string operators and numbers from numeric operators and the rest is on a need to know basis\, which mostly means XS is involved.

Some people will do the wrong thing regardless. You cannot help that.

2. It does not make a good argument against the patch because people *already* try to write such code with such as `looks_like_number`;

Actually\, there is nothing wrong with looks_like_number\, as code using it will treat 3 and "3" the same way. In fact\, Perl’s unary negation uses it. Any string beginning with [a-zA-Z]\, or any string that begins with '-' and !looks_like_number gets string negation. Anything else gets numeric negation. (Or at least that’s how it is in bleadperl\, now that I’ve fixed the inconsistencies.)

Well… it depends\, on what it’s trying to do. If you’re trying to write a JSON serializer using looks_like_number the result will be broken. It will produce number values in cases where it should spit out string values\, and\, rarely\, vice versa\, with no good way of controlling it. So you need some other signalling mechanism for this.

There are other cases… I know I had code that I couldn’t make work well in some other circumstance\, where looks_like_number was only the nearest best thing to do. I wish I could remember what exactly it was.

With Chip’s patch this problem would go away.

this patch would at least allow such code to work better in those cases where that is motivated by a legitimate desire\,

I still think looks_like_number is a better approach in most cases.

Yes well\, as I said\, depending on what you are doing.

Essentially your patch\, to me\, boils down to more reliable serialisation for formats with a data model pickier than Perl’s\,

If that is the reason for it\, then I am not opposed\, as long as the documentation for the API makes it clear that using it to treat arguments to functions differently is not its intended use and goes against the spirit of everything Perl 5 stands for.

Let’s not have a repeat of the Unicode bug.

Absolutely. See above.

as well as fewer bugs in the bitwise operators (which really means those operators should be redesigned and the old design removed with prejudice; unfortunately that is a lot less realistic than it is for smartmatch)\,

Not at all. Perl 6 has +| and +&\, so why can’t Perl 5? Probably because +~ already means something\, right? ~| is how Perl 6 does stringwise bitwise or. But ~ never means string in Perl 5\, so we would have to come up with something else. Maybe a feature feature could make | ^ stringwise.

Hmm.

The idea that this could be fixable is more than a little tempting…

Do you think we could also eventually untangle C\ from C\<x()> the way that Perl 6 has? :-)

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 12 years ago

From @chipdude

On Fri\, Jul 13\, 2012 at 11:27:32AM +0200\, Aristotle Pagaltzis wrote:

There is no need for the magicflags patch to repeat these [utf8] mistakes. It need not come with an `is_string` function.

I was *just* thinking the same thing this morning. It all depends on what the meaning of "is" is\, as a famous lawyer once said. The predicate "is a string" is NOT what the patch offers\, so a test named "isstring" is wrong.

My current best choice is "created_as_string"\, "created_as_integer"\, "created_as_number"\, "created_as_boolean". And perhaps "created_as" returning 'INT'\, 'NUM'\, 'STR'\, 'BOOL'\, and possibly other values depending on what's handy. These names tell the truth\, as all we can reveal is the way a value was created\, not what it _is_ in any existential sense.

We can bikeshed the name\, but the principle seems right to me.

(I expect these would go in Scalar::Util.)

If you’re trying to write a JSON serializer using looks_like_number the result will be broken.

Exactly so. -- Chip Salzenberg

Perl / perl5