Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Perl>
  3. porters
[perl #113818] List::Util::first() don't work into when() context
perlbug-followup at perl
Jun 24, 2012, 11:25 AM
Post #1 of 43 (4084 views)
Permalink
# 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@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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
b2gills at gmail
Jun 26, 2012, 5:36 PM
Post #2 of 43 (4013 views)
Permalink
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.perl.org:443/rt3/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
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-comment at perl
Jun 27, 2012, 4:35 AM
Post #3 of 43 (3983 views)
Permalink
Alternately, you can continue using given/when and refer to $::_ in your first block, rather than
$_.

I suggest ditching given/when, though.
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rgs at consttype
Jun 27, 2012, 5:37 AM
Post #4 of 43 (3982 views)
Permalink
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.
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
fawaka at gmail
Jun 27, 2012, 6:49 AM
Post #5 of 43 (3984 views)
Permalink
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
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jun 27, 2012, 8:18 AM
Post #6 of 43 (3987 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perl.p5p at rjbs
Jun 27, 2012, 10:53 AM
Post #7 of 43 (3982 views)
Permalink
* 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

Attached Files:

Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
aaron at priven
Jun 27, 2012, 12:07 PM
Post #8 of 43 (3984 views)
Permalink
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
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-comment at perl
Jun 27, 2012, 12:32 PM
Post #9 of 43 (3982 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rgs at consttype
Jun 27, 2012, 3:03 PM
Post #10 of 43 (3993 views)
Permalink
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.)
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perl.p5p at rjbs
Jun 27, 2012, 5:12 PM
Post #11 of 43 (3991 views)
Permalink
* 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

Attached Files:

Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
aaron at priven
Jun 27, 2012, 5:29 PM
Post #12 of 43 (3981 views)
Permalink
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.org>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@priven.com
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jun 27, 2012, 6:19 PM
Post #13 of 43 (3985 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jun 27, 2012, 8:45 PM
Post #14 of 43 (3983 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
mail at steffen-mueller
Jun 27, 2012, 10:29 PM
Post #15 of 43 (3991 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
jvromans at squirrel
Jun 27, 2012, 11:13 PM
Post #16 of 43 (3983 views)
Permalink
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
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jun 27, 2012, 11:19 PM
Post #17 of 43 (3986 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rs at 474
Jun 28, 2012, 6:21 AM
Post #18 of 43 (3981 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
dmcbride at cpan
Jun 28, 2012, 6:53 AM
Post #19 of 43 (3993 views)
Permalink
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.

Attached Files:

[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jun 28, 2012, 8:24 AM
Post #20 of 43 (3982 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rs at 474
Jun 28, 2012, 9:17 AM
Post #21 of 43 (3982 views)
Permalink
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
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jun 28, 2012, 9:38 AM
Post #22 of 43 (3984 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
doy at tozt
Jun 28, 2012, 9:49 AM
Post #23 of 43 (3983 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rs at 474
Jun 28, 2012, 10:08 AM
Post #24 of 43 (3984 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
doy at tozt
Jun 28, 2012, 10:23 AM
Post #25 of 43 (4005 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
liz at dijkmat
Jun 28, 2012, 11:01 AM
Post #26 of 43 (862 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
fawaka at gmail
Jun 28, 2012, 1:27 PM
Post #27 of 43 (855 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
smueller at cpan
Jun 28, 2012, 11:02 PM
Post #28 of 43 (853 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jun 29, 2012, 4:46 PM
Post #29 of 43 (860 views)
Permalink
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.
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jul 3, 2012, 8:16 AM
Post #30 of 43 (855 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
pagaltzis at gmx
Jul 10, 2012, 10:27 PM
Post #31 of 43 (834 views)
Permalink
* 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/>
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jul 11, 2012, 12:29 AM
Post #32 of 43 (832 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
pagaltzis at gmx
Jul 11, 2012, 2:02 AM
Post #33 of 43 (834 views)
Permalink
* 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/>
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
b2gills at gmail
Jul 11, 2012, 8:33 AM
Post #34 of 43 (831 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jul 11, 2012, 11:37 AM
Post #35 of 43 (823 views)
Permalink
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.
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jul 11, 2012, 12:38 PM
Post #36 of 43 (827 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jul 11, 2012, 3:33 PM
Post #37 of 43 (824 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
pagaltzis at gmx
Jul 12, 2012, 2:35 AM
Post #38 of 43 (822 views)
Permalink
* 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/>
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jul 12, 2012, 7:15 PM
Post #39 of 43 (823 views)
Permalink
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
[perl #113818] List::Util::first() don't work into when() context [ In reply to ]
perlbug-followup at perl
Jul 13, 2012, 12:15 AM
Post #40 of 43 (831 views)
Permalink
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


---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113818
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jul 13, 2012, 12:39 AM
Post #41 of 43 (822 views)
Permalink
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
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
pagaltzis at gmx
Jul 13, 2012, 2:27 AM
Post #42 of 43 (824 views)
Permalink
* 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.

Hmm.

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

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

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: [perl #113818] List::Util::first() don't work into when() context [ In reply to ]
rev.chip at gmail
Jul 13, 2012, 12:33 PM
Post #43 of 43 (825 views)
Permalink
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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal