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

[Joaquin Ferrero]

# 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 expl...@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

[Brad Gilbert]

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

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

[Ricardo SIGNES via RT]

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

I suggest ditching given/when, though.

[Rafael Garcia-Suarez]

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

[Leon Timmermans]

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

Leon

[Father Chrysostomos via RT]

On Wed Jun 27 05:37:31 2012, r...@consttype.org wrote:
> On 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-

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

[Aaron Priven]

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

On Wed Jun 27 05:37:31 2012, r...@consttype.org wrote:
> On 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-
> com...@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, aa...@priven.com

[Father Chrysostomos via RT]

On Wed Jun 27 10:53:54 2012, perl...@rjbs.manxome.org wrote:
> * Father Chrysostomos via RT <perlbug-...@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

[Rafael Garcia-Suarez]

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

[Aaron Priven]

On Wed, Jun 27, 2012 at 3:03 PM, Rafael Garcia-Suarez <r...@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...@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, aa...@priven.com

[Father Chrysostomos via RT]

On Wed Jun 27 17:13:21 2012, perl...@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 RT]

On Wed Jun 27 18:19:21 2012, sprout wrote:
> On Wed Jun 27 17:13:21 2012, perl...@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! :-)

[Johan Vromans]

Ricardo Signes <perl...@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

[Father Chrysostomos via RT]

+27.93

[Robert Sedlacek]

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

[Darin McBride]

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.

[Father Chrysostomos via RT]

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

[Robert Sedlacek]

On Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
> On Thu Jun 28 06:53:40 2012, dmcb...@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

[Father Chrysostomos via RT]

On Thu Jun 28 09:17:43 2012, r...@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, dmcb...@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?

[Jesse Luehrs]

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

[Robert Sedlacek]

On Thu, 2012-06-28 at 09:38 -0700, Father Chrysostomos via RT wrote:
> On Thu Jun 28 09:17:43 2012, r...@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, dmcb...@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

[Jesse Luehrs]

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

[Elizabeth Mattijsen]

On Jun 28, 2012, at 6:38 PM, Father Chrysostomos via RT wrote:
> On Thu Jun 28 09:17:43 2012, r...@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, dmcb...@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

[Leon Timmermans]

On Thu, Jun 28, 2012 at 6:17 PM, Robert Sedlacek <r...@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, dmcb...@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

[Steffen Mueller]

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

[Steffen Mueller]

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...@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

[Ed Avis]

Father Chrysostomos via RT <perlbug-followup <at> perl.org> writes:

>Oh, and let’s deprecate smartmatch while we are at it.

I agree, and for the one case where smartmatch is useful in practice:

if ($x ~~ @values) { ... }

add a new operator 'in' borrowed from Python

if ($x in @values) { ... }

which does an 'eq' comparison with each item in the list, stopping and returning
true if one matches, false otherwise.

I would gladly remove smartmatch from my code if Perl provided an 'in' keyword
to replace it, which is the only thing I use smartmatch for anyway.

--
Ed Avis <e...@waniasset.com>

[Klaus]

I agree with your statement, but the problem is that there is always
something to be added, for example: what about numeric values ? --> so
it seems reasonable to add an '==' comparison for numeric values, but
hey, we also want text that looks like a number to be treated like a
number, so we add '==' comparison for that, too, and so on...

...so we finally arrive at the same mess with 'in' as we already have
with ~~.

Maybe two versions of 'in' might be in order, 'in_eq' for text
comparison and in_== for numeric comparison. But again, there is
probably a better way...

You see, it never stops.

[Aaron Priven]

On Fri, Jun 29, 2012 at 12:15 PM, Klaus <kla...@gmail.com> wrote:

On 29 juin, 12:54, e...@waniasset.com (Ed Avis) wrote:
> Father Chrysostomos via RT <perlbug-followup <at> perl.org> writes:
> I would gladly remove smartmatch from my code if Perl provided an 'in' keyword
> to replace it, which is the only thing I use smartmatch for anyway.

I agree with your statement, but the problem is that there is always
something to be added, for example: what about numeric values ? --> so
it seems reasonable to add an '==' comparison for numeric values, but
hey, we also want text that looks like a number to be treated like a
number, so we add '==' comparison for that, too, and so on...

Isn't "text that looks like a number" the whole point of distinguishing between eq and == ? That's really the same thing. 

 

...so we finally arrive at the same mess with 'in' as we already have
with ~~.

Maybe two versions of 'in' might be in order, 'in_eq' for text
comparison and in_== for numeric comparison. But again, there is
probably a better way...

You see, it never stops.

It seems to me that the point of replacing smartmatch with "in" is to avoid the ambiguity of smartmatch, where it's difficult to tell which of all the different types of comparisons will be used at any one time. Father Chrysostomos postulates an "in" that means only one thing: an is-an-element lookup, using "eq". This is just one of the many different smartmatch comparisons, but it avoids the problem: it removes the ambiguity.

Yes, in theory, somebody could decide that perl needed *all* the smartmatch comparisons to be operators. Even if all of them were added -- with alternate eq/== versions as necessary -- they wouldn't cause the problems that smartmatch causes.

In the long run people may decide that other smartmatch comparisons may also be useful to retain as separate operators, whether that's in-an-element lookup using == , or the more esoteric ones like "hash keys intersection" for %hash ~~ @array. Some will, and some won't. But at least the ambiguity would be gone. And it's that ambiguity -- DWIMmery gone mad -- that is most problematical.

I do think in_eq and in_== would be useful, and with when_true, when_eq, and when_== would cover nearly all the actual uses of smartmatch in practice.

-- 

Aaron Priven, aa...@priven.com

[Reverend Chip]

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.

[Klaus]

On 29 juin, 23:05, aa...@priven.com (Aaron Priven) wrote:

> On Fri, Jun 29, 2012 at 12:15 PM, Klaus <klau...@gmail.com> wrote:
> > On 29 juin, 12:54, e...@waniasset.com (Ed Avis) wrote:
> > > I would gladly remove smartmatch from my code if Perl provided
> > > an 'in' keyword
> > > to replace it, which is the only thing I use smartmatch for anyway.

> > I agree with your statement, but the problem is that there is always
> > something to be added,

[...]

> I do think in_eq and in_== would be useful, and with when_true, when_eq,
> and when_== would cover nearly all the actual uses of smartmatch in
> practice.

That sounds very reasonable to me. I suggest that we use this as a
proposal to the perl5.porters community to develop a new smartmatch /
given...when.

[Elizabeth Mattijsen]

On Jun 29, 2012, at 2:16 PM, Ricardo Signes wrote:
> * Ed Avis <e...@waniasset.com> [2012-06-29T06:54:55]

>> add a new operator 'in' borrowed from Python
>>
>> if ($x in @values) { ... }
>

> Perl6::Junction provides any().
>
> if ($x eq any(@values)) { ... }
> if ($x == any(@values)) { ... }

Maybe a nice project for Devel::Declare encapsulating List::MoreUtils::any ?



Liz

[Ed Avis]

Just a couple more thoughts on the suggestion of an 'in' operator
(which others besides me have proposed).

The current convention is that punctuation operators like == != < are
numeric, while alphabetic ones like eq ne lt do string comparisons.
An 'in' operator doing string comparison follows that convention.
While you could also have an equivalent in== operator, in my
experience that operation is much less common than the string version.

As in Python, 'in' could work for both arrays and hashes:

$x in @array

$x in %hash # same as exists $hash{$x}

With the auto-dereferencing introduced in recent perls, the RHS could
be an array or hash ref.

$x in $hash_ref # same as exists $hash_ref->{$x}

I do not envisage the 'in' operator being part of some grand scheme
which will replace all functionality provided by smartmatch, but just
propose it as a simple operator which is useful in its own right and,
in my opinion, can make for clearer and more concise code.

--
Ed Avis <e...@waniasset.com>

[David Mertens]

Ed,

I have a few thoughts about introducing "in" as a new infix operator.

1) Why would "$a in %hash" be equivalent to "exists $hash{$a}"? It seems that it would be conceptually closer to (and much more useful as) "$a in values %hash".

2) PDL defines a method called "in" and it is exported when a user has "use PDL" in their code (i.e. it is very typically exported). The basic convention is "in($needle, $haystack)". PDL also defines methods "any" and "all" which returns a boolean true value if any value or all values in its argument piddle is nonzero. These methods are typically used as

    if (any $first == $second) { ... }
    if (all $first == $second) { ... }

Because these methods are exported by default, it is quite conceivable that users could have the following in their code:

if ( any in $needle => $haystack ) {
    ...
}

which would be more verbosely written as

if ( any (in ($needle => $haystack) ) ) {
    ...
}

Now, as you can see, we get into some murky backward compatibility issues. As long as this is properly handled with "use feature 'in'" or some such, then I have no qualms putting code in PDL that handles "in" differently based on the current feature set. I'll need some pointers on how to determine the current feature set that was requested by the user when they import PDL's functions, but we can do that. (And, I'll need some pointers about how to handle things if the user says "use PDL; use features 'in'", since in that case the import mechanism will think that the user won't have feature 'in' at import time.)

3) Continuing from #2: If a user decides to use the old form of in because they've trained their fingers that way:

    use PDL;
    use feature qw(in say);
    my $haystack = sequence(10);
    my $needles = pdl(-1, 5, 17);
    say "Some of $needles were found in $haystack"
        if any in $needles => $haystack;

how is that parsed, and what sort of error reporting happens? I expect that this will try to call PDL's any method without any arguments and then see if the returned value is in $needles? If that is the case, the user will get an error about not specifying enough arguments to the any method [1], which would be confusing at best. Obviously there would be no way for our "any" method to know that it's being called in the context of an "in" statement, so we wouldn't be able to craft a more tailored error message.

4) As with all other infix operators it would be great to be able to override the infix operator because it would allow for code like this, which reads like English:

if (any $needle in $haystack ) {
    ...
}

So I like the idea in general, but I have backward compatibility concerns in mind. do you have any specific ideas for handling these concerns?

David

[1] Actually, at the moment PDL doesn't even check its arguments to "any":

perl -MPDL -e 'any'
Can't call method "clump" on an undefined value at /home/david/perl5/lib/perl5/i686-linux-gnu-thread-multi-64int/PDL/Ufunc.pm line 1493.

Looks like I need to file (and fix) a bug, then.

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

[Father Chrysostomos via RT]

On Thu Jun 28 23:03:02 2012, smue...@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.

[Ed Avis]

David Mertens asked:

>Why would "$a in %hash" be equivalent to "exists $hash{$a}"?

This is how it works in Python, and it seems natural in Perl too.
You could write '$a in values %hash' if you wanted that.
In my experience testing for hash membership by key is much more
common than by value, and '$a in %h' is a clearer way to express it
than 'exists $h{$a}', especially when dealing with hash references.

>PDL defines a method called "in"

Hmm. I imagine that adding the new 'in' keyword would have to be
protected by 'use 5.6789' or similar. It might lead to some interesting
clashes with subroutines called 'in'. Such code would either have to
explicitly qualify it as PDL::in, or not have 'use 5.6789', or have
"no feature 'in'" to disable the builtin keyword.

--
Ed Avis <e...@waniasset.com>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Aaron Crane]

Ed Avis <e...@waniasset.com> wrote:
> David Mertens asked:
>>Why would "$a in %hash" be equivalent to "exists $hash{$a}"?
>
> This is how it works in Python, and it seems natural in Perl too.

It doesn't seem particularly natural to me: I find it bletcherous
that, in Python, you can't statically tell the difference between an
O(1) dict-existence test and an O(N) sequence-containment test (let
alone a sequence-subsumption test). Given that we already have a
perfectly cromulent operator for testing hash existence, and that the
existing builtins that DWIM between array refs and hash refs aren't
widely liked, I'm inclined to think that, if we acquire such an `in`
operator, it shouldn't allow a hash on its RHS.

Beyond that, I'm not at all convinced that this `in` is powerful
enough to justify its own existence (regardless of whether it
replicates the behaviour of `exists` on a hash). If it can only do
string comparison, there are a variety of common tasks where you have
to write out a longhand equivalent anyway; if it guesses as to whether
you meant string equality or numeric equality or regex match or what
have you, then it repeats essentially all the problems of smartmatch
as currently implemented.

The more I consider this, the more strongly I think that a wordier API
is the right thing — along the lines of Test::Deep (now maintained by
our fearless pumpking) or Leon's Smart::Match. I offer the following
anecdotal support for this position. I currently have a codebase
which makes substantial use of List::MoreUtils::any and friends for
higher-order list-wise tests. By my reckoning, only about one
occurrence in ten could be refactored to use an `in` operator of the
form you suggest; but every single occurrence can be refactored to use
Smart::Match (and almost all of them are made much clearer by doing
so).

--
Aaron Crane ** http://aaroncrane.co.uk/

[Eric Brine]

On Tue, Jul 3, 2012 at 12:52 PM, Ed Avis <e...@waniasset.com> wrote:

David Mertens asked:

>Why would "$a in %hash" be equivalent to "exists $hash{$a}"?

This is how it works in Python, and it seems natural in Perl too.
You could write '$a in values %hash' if you wanted that.

Actually, you couldn't with the previously mentioned syntax. It would be

    $a in @{[ values %hash ]}

Or using the later suggested shortcut, it would be

    $a in [ values %hash ]

[Jesse Luehrs]

On Tue, Jul 03, 2012 at 01:58:45PM -0400, Eric Brine wrote:

> On Tue, Jul 3, 2012 at 4:59 AM, Ed Avis <e...@waniasset.com> wrote:
>
> > As in Python, 'in' could work for both arrays and hashes:
> >
> > $x in @array
> >
> > $x in %hash # same as exists $hash{$x}
> >
>

> So C<< $x in @array >> checks the values, and C<< $x in %hash >> checks the
> keys? Isn't that confusing?

This sort of thing is why I never liked the smartmatch behavior for
arrays and hashes either. It picks one arbitrary interpretation, and
blesses it with special syntax. Being explicit about what you mean (via
something like Smart::Match or Perl6::Junction) is a much much better
idea.

-doy

[Eric Brine]

On Tue, Jul 3, 2012 at 4:59 AM, Ed Avis <e...@waniasset.com> wrote:

As in Python, 'in' could work for both arrays and hashes:

   $x in @array

   $x in %hash    # same as exists $hash{$x}

So C<< $x in @array >> checks the values, and C<< $x in %hash >> checks the keys? Isn't that confusing?

With the auto-dereferencing introduced in recent perls, the RHS could
be an array or hash ref.

yuck. I still think the cost of not working for all hashes and arrays is too high.

[Leon Timmermans]

On Tue, Jul 3, 2012 at 8:02 PM, Jesse Luehrs <d...@tozt.net> wrote:
> This sort of thing is why I never liked the smartmatch behavior for
> arrays and hashes either. It picks one arbitrary interpretation, and
> blesses it with special syntax. Being explicit about what you mean (via
> something like Smart::Match or Perl6::Junction) is a much much better
> idea.

Yeah. I find the arbitrariness much more problematic than anything
else about smartmatch, sometimes it feels like it was designed using
dice. At least with the string/number issue, it's obvious why they
wanted it to work like that.

Leon

[Reverend Chip]

In fairness, that description matches *all* language design, especially
Perl's.

[Reverend Chip]

On 7/4/2012 2:40 AM, Leon Timmermans wrote:
> At least with the string/number issue, it's obvious why they
> wanted it to work like that.

Also, a gentle reminder that with magicflags in place the strings and
numbers will work even better.

[Aaron Priven]

On Tue, Jul 3, 2012 at 1:59 AM, Ed Avis <e...@waniasset.com> wrote:

The current convention is that punctuation operators like == != < are
numeric, while alphabetic ones like eq ne lt do string comparisons.
An 'in' operator doing string comparison follows that convention.
While you could also have an equivalent in== operator, in my
experience that operation is much less common than the string version.

In an earlier message I talked about "in_eq" and "in_==" and so forth, but I didn't intend those to be the actual names in use. I agree that the convention is that numeric versions of operators use punctuation, and I had imagined that there would be one created for "in_==", although I don't know which punctuation characters could be used without causing conflicts in the parser or what symbols might best signify in_== (although, of course, in Unicode there's an "is-an-element" symbol, ∈ ).

 

As in Python, 'in' could work for both arrays and hashes:

   $x in @array

   $x in %hash    # same as exists $hash{$x}

Is that what it does in Python? I thought it would be more useful applied to the values of a hash, since (just as with arrays) we have no easy way of doing that now with hash values, and the values of an array are analogous to the values, not the keys, of a hash. And we already have exists $hash{$x}.

--
Aaron Priven, aa...@priven.com

[Aaron Priven]

On Jul 5, 2012, at 7:47 PM, Ricardo Signes wrote:

> * Ed Avis <e...@waniasset.com> [2012-07-03T04:59:34]

>> As in Python, 'in' could work for both arrays and hashes:
>>
>> $x in @array
>>
>> $x in %hash # same as exists $hash{$x}
>

> Alas, Perl is not Python, and alas, Python is not Perl. The "in" operator in
> Python works nicely because Python's type system is different to Perl's.
>
> We're not going to be adding an `in` operator, because it goes against the
> idea of where Perl decides what type to use. Fortunately, Perl6::Junction and
> other libraries provide excellent tools for doing this kind of scanning. I use
> them all the time and don't regret it for a second.

Hmm.

I can understand how an "in" operator might have typing issues, especially if, as above, it works "for both arrays and hashes" (which means that it doesn't just flatten the hash into a list). I didn't realize that until I sat down and thought about what you wrote here.

But at its simplest, an "in" operator could be a shorter, faster, infix version of this:

sub in {
my $member = shift;
for (@_) {
return 1 if $member eq $_;
}
return q{};
}

Except for the use of "eq", it doesn't assume anything about the type of anything. And inferring numeric / string from the operator is what, I thought, Perl did. Hence the suggestion of a numeric "in" operator.

That's not to say it's necessarily worth doing. Maybe, as Aaron Crane suggests, it's not "powerful enough to justify its own existence."

I personally think "$x in (list)" is clearer and easier to understand than the alternatives -- $x eq any((list)); List::MoreUtils::any {our $_; $_ eq $member} (list); copying and pasting the loop each time; or, for that matter, using "in" as a regular sub. And I do use "$x ~~ @list" somewhat frequently, so to me it would be nice to have a simple and equivalent replacement without the ambiguity of smartmatch.

That's just my opinion, and not worth much, of course.

But it is possible to separate the idea of the in operator from the problematic assumptions about types that come from smartmatch, or from treating Perl like Python, and consider "in" on its own merits.

[Brad Baxter]

On 7/5/12, Aaron Priven <aa...@priven.com> wrote:
> In an earlier message I talked about "in_eq" and "in_==" and so forth, but
> I didn't intend those to be the actual names in use. I agree that the
> convention is that numeric versions of operators use punctuation, and I had
> imagined that there would be one created for "in_==", although I don't know
> which punctuation characters could be used without causing conflicts in the
> parser or what symbols might best signify in_== (although, of course, in
> Unicode there's an "is-an-element" symbol, ∈ ).

<bikeshed>

if ($x ~> @values) { ... }

</bikeshed>

--
Brad

[Leon Timmermans]

On Sat, Jun 30, 2012 at 4:23 PM, Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
> Maybe a nice project for Devel::Declare encapsulating List::MoreUtils::any ?

Or better yet, Devel::CallParser. Though I'm not sure how to use
either to create an infix operator.

Leon

[Aaron Priven]

It seems reasonable to me to argue that "in" is too specific, or not powerful enough, to bother including in Perl, compared to more flexible constructs such as the any() provided by Perl6::Junction. I don't agree with that, because I think "is this an element of that list" is a basic concept that is very commonly needed, and which deserves to have an easy and utterly clear way to write it, and I think "$x in (list)" is a lot clearer than "$x eq any(list)". But it's certainly reasonable to think otherwise.

But that has nothing to do with types. You wrote originally:

> We're not going to be adding an `in` operator, because it goes against the
> idea of where Perl decides what type to use.

The simple version of "in" I have discussed does no such thing. It has exactly the same treatment of numeric and string type as all the existing comparative operators, each of which comes in numeric and string flavors. Yes, each of those flavors would need to be justified as useful to bother including it in Perl. But they are entirely consistent with Perl's treatment of types.

On Fri, Jul 6, 2012 at 5:13 AM, Ricardo Signes <perl...@rjbs.manxome.org> wrote:

The use of "eq" is the primary type issue.  If we need a numeric in, then now

we're talking about *two* operators to justify, each with one very specific
use.  On the other hand, you can use any() with all sorts of comparitors and
values.

--
Aaron Priven, aa...@priven.com

[David Mertens]

On Fri, Jul 6, 2012 at 12:20 PM, Ricardo Signes <perl...@rjbs.manxome.org> wrote:

* Aaron Priven <aa...@priven.com> [2012-07-06T13:02:50]

> It seems reasonable to me to argue that "in" is too specific, or not
> powerful enough, to bother including in Perl, compared to more flexible
> constructs such as the any() provided by Perl6::Junction. I don't agree
> with that, because I think "is this an element of that list" is a basic
> concept that is very commonly needed, and which deserves to have an easy
> and utterly clear way to write it, and I think "$x in (list)" is a lot
> clearer than "$x eq any(list)". But it's certainly reasonable to think
> otherwise.
>
> But that has nothing to do with types. You wrote originally:
>
> > We're not going to be adding an `in` operator, because it goes against the
> > idea of where Perl decides what type to use.

It does, because in Perl 5, the question of type is often embedded in the
operator.  == forces its operands to act as numbers.  eq, as strings.

If the values held the types, `in` would be straightforward.  In Perl 5, the
operators hold the types, so `in` would have to pick a type of its own.

--
rjbs

But Aaron is suggesting that `in` would always pick the string type. We then need a symbol for numeric type, though I cannot conceive of one.

[Aaron Priven]

On Fri, Jul 6, 2012 at 10:20 AM, Ricardo Signes <perl...@rjbs.manxome.org> wrote:

If the values held the types, `in` would be straightforward.  In Perl 5, the
operators hold the types, so `in` would have to pick a type of its own.

Yes. The idea is that "in" picks the string type, and numeric-in, which would have some symbol, would pick the numeric type. We can disagree about whether these would be good to have for other reasons, but I don't think, reasonably, it can be said that the idea "goes against the idea of where Perl decides what type to use." 

It's smartmatch that did that, and I completely sympathize with the desire to avoid going down the smartmatch road again. But, even though this conversation did start out heading vaguely in that direction, by referring to Python's in, we're off that road now.

On Fri, Jul 6, 2012 at 10:31 AM, David Mertens <dcmerte...@gmail.com> wrote:

But Aaron is suggesting that `in` would always pick the string type.

 

Yes. The idea is that "in" would force its operands to be strings, exactly the way eq does. And numeric-in would force its operands to be numbers, just the way == does. And it has to be that way, precisely because, as rjbs says, the question of type is embedded in the operators.

We then need a symbol for numeric type, though I cannot conceive of one.

"Need" is a bit strong -- string in would still be useful on its own.

I can think of lots of symbols that could mean numeric "in", but I'll let others bikeshed that.

-- 

Aaron Priven, aa...@priven.com

[Klaus]

On 6 juil, 21:00, aa...@priven.com (Aaron Priven) wrote:

> On Fri, Jul 6, 2012 at 10:31 AM, David Mertens <dcmertens.p...@gmail.com>wrote:
>
> > But Aaron is suggesting that `in` would always pick the string type.
>
> Yes. The idea is that "in" would force its operands to be strings, exactly
> the way eq does. And numeric-in would force its operands to be numbers,
> just the way == does. And it has to be that way, precisely because, as rjbs
> says, the question of type is embedded in the operators.
>
> We then need a symbol for numeric type, though I cannot conceive of one.
> "Need" is a bit strong -- string in would still be useful on its own.
>
> I can think of lots of symbols that could mean numeric "in", but I'll let
> others bikeshed that.

Someone already suggested "~>" for numeric "in", which sounds good for
me.

I would also suggest to add the additional forms of "when", for
example "when_str", "when_num" and "when_true" to have the following
meaning:

my $var = '007';

given ($var) {
when_num(7) {...}
# means $num == 7
when_num([6, 7, 8]) {...}
# means $num ~> (6, 7, 8)
when_str('007') {...}
# means $txt eq '007'
when_str(['006', '007', '008']) {...}
# means $txt in ('006', '007', '008')
when_true(chr($_) eq 'a') {...}
# evaluates the condition
}

Finally, let's replace the lexical topicalizer $_ by a local $_.

With these changes I believe we have a sane given/when/smartmatch
implementation.

[Klaus]

On 8 juil, 14:24, klau...@gmail.com (Klaus) wrote:
>        # means $num == 7

>        # means $num ~> (6, 7, 8)

>        # means $txt eq '007'

>        # means $txt in ('006', '007', '008')

Sorry, a minor error in the comments above, this should, of course be:

# means $_ == 7
# means $_ ~> (6, 7, 8)
# means $_ eq '007'
# means $_ in ('006', '007', '008')

[Dr.Ruud]

On 2012-07-06 21:00, Aaron Priven wrote:

> The idea is that "in" picks the string type, and numeric-in, which
> would have some symbol, would pick the numeric type.

For example '%' or rather '@':


perl -wle 'print 4 % ( 0, 1, 1, 5, 2, -3 )'
Useless use of a constant (5) in void context at -e line 1.
Useless use of a constant (2) in void context at -e line 1.
-2


perl -wle 'print 4 @( 0, 1, 1, 5, 2, -3 )'
Array found where operator expected at -e line 1, near "4 "
(Missing operator before ?)
Number found where operator expected at -e line 1, near "@( 0"
(Missing operator before 0?)
syntax error at -e line 1, near "4 @( "
Execution of -e aborted due to compilation errors.


--
Ruud

[Aaron Priven]

On Sun, Jul 8, 2012 at 5:24 AM, Klaus <kla...@gmail.com> wrote:

I would also suggest to add the additional forms of "when", for

example "when_str", "when_num" and "when_true" to have the following
meaning:

my $var = '007';

given ($var) {
    when_num(7) {...}
       # means $num == 7
    when_num([6, 7, 8]) {...}
       # means $num ~> (6, 7, 8)

Well, doing that makes it impossible to do this:

given ($arrayref) {

  when_num ($first_arrayref) { 

    do_something();

  }

  when_num ($second_arrayref) {

    do_something_else();

  }

}

And, since == is used for referential equality, that's not at all unreasonable.

Your construct could still be done with when_true, if one likes punctuation:

  when_true($_ ~> [6, 7, 8] )

(I think "in" could only take a list, so probably one wouldn't need the @{ } dereference, as with push or each, but I'm not sure )

On the other hand, "for" uses semicolons to separate items that are part of its conditional. I guess "when_num" could do the same thing:

   when_num ( 5; 15; 25; 173; 382) {

     do_something():

   }

Am I nuts for that one?

(I'm not endorsing any of the specific names of functions or operators used here, especially since I don't think builtins should have underlines in them. And note that ~> was proposed just the other day for a return-undef-not-an-exception ->.)

--
Aaron Priven, aa...@priven.com

[Johan Vromans]

Klaus <kla...@gmail.com> writes:

> I would also suggest to add the additional forms of "when", for
> example "when_str", "when_num" and "when_true" to have the following
> meaning:

Lets take a few staps back and look again.

Perl did not have a 'switch' statement, and that was perceived to be
good since there were several other ways to obtain the same behaviour.

With given/when/smartmatching a feature was introduced that unified
comparison and matching, providing a nice and elegant 'switch'
statement.

It turned out to have several limitations, ranging from ununderstood
smartmatch magic to syntactical/semantical behavour problems.

Trying to overcome these limitations by adding "when_str" and such
destroys the "nice and elegant" part of given/when.

Remember it is not *necessary* to fix the limitations, since there have
always been several other ways to obtain the same behaviour.

-- Johan

[Nicholas Clark]

On Tue, Jul 10, 2012 at 08:28:11AM +0200, Johan Vromans wrote:

> Remember it is not *necessary* to fix the limitations, since there have
> always been several other ways to obtain the same behaviour.

Thanks. That's a very useful clarification/insight.

Nicholas Clark

[Abigail]

On Tue, Jul 03, 2012 at 01:58:45PM -0400, Eric Brine wrote:

> On Tue, Jul 3, 2012 at 4:59 AM, Ed Avis <e...@waniasset.com> wrote:
>
> > As in Python, 'in' could work for both arrays and hashes:
> >
> > $x in @array
> >
> > $x in %hash # same as exists $hash{$x}
> >
>
> So C<< $x in @array >> checks the values, and C<< $x in %hash >> checks the
> keys? Isn't that confusing?

Not for me.



Abigail

[Aaron Priven]

On Mon, Jul 9, 2012 at 11:28 PM, Johan Vromans <jvro...@squirrel.nl> wrote:

Lets take a few staps back and look again.

Perl did not have a 'switch' statement, and that was perceived to be
good since there were several other ways to obtain the same behaviour.

Perceived by whom? Not by the people who wrote Switch.pm. Not by the people who created given/when in the first place. Not by the people who have been discussing this.

With given/when/smartmatching a feature was introduced that unified
comparison and matching, providing a nice and elegant 'switch'
statement.

It turned out to have several limitations, ranging from ununderstood
smartmatch magic to syntactical/semantical behavour problems.

Trying to overcome these limitations by adding "when_str" and such
destroys the "nice and elegant" part of given/when.

I pretty much disagree with every single thing you just wrote here. The idea that you seem to think is "nice and elegant" is that we have a single construct that looks at its argument and does the right thing with it depending on what that argument is. That's the basis of smartmatch and even more so of "when". But its perceived elegance comes at the cost of clarity. It looks simple when written down, but the hidden complexity is still there, and that hidden complexity makes it much, much harder to understand what it's doing, which means it's much, much harder to maintain.

Remember it is not *necessary* to fix the limitations, since there have
always been several other ways to obtain the same behaviour.

There are always several other ways of doing anything in Perl. That might almost be Perl's slogan. In fact...

The question is whether a switch statement is useful. Does it make programs easier to write and easier to read? I think so. But the over-the-top DWIMery of smartmatch and when destroy that usefulness, by making it unclear what exactly is happening. Making the different types of "when" explicit rather than implicit makes the complexity apparent rather than papering it over. And that, in my opinion, is what is "nice and elegant".

--
Aaron Priven, aa...@priven.com

[Nicholas Clark]

On Tue, Jul 10, 2012 at 11:44:19AM -0700, Aaron Priven wrote:

> The question is whether a switch statement is useful. Does it make programs
> easier to write and easier to read? I think so. But the over-the-top
> DWIMery of smartmatch and when destroy that usefulness, by making it
> unclear what exactly is happening. Making the different types of "when"
> explicit rather than implicit makes the complexity apparent rather than
> papering it over. And that, in my opinion, is what is "nice and elegant".

But I can achieve the same with a chained sequence of
if()/elsif()/elsif()/else

And within the condition blocks I can be explicit about the "when".

And that uses less total syntax than the proposal for distinct "when"
operators.

And that makes the language easier to learn, and maintain (which is a benefit)
at a cost (less expressiveness). It's all a question of trade off.

Nicholas Clark

[Klaus]

On 10 juil, 08:28, jvrom...@squirrel.nl (Johan Vromans) wrote:

> Klaus <klau...@gmail.com> writes:
> > I would also suggest to add the additional forms of "when", for
> > example "when_str", "when_num" and "when_true" to have the following
> > meaning:
>
> Lets take a few staps back and look again.
>
> Perl did not have a 'switch' statement, and that was perceived to be
> good since there were several other ways to obtain the same behaviour.
>
> With given/when/smartmatching a feature was introduced that unified
> comparison and matching, providing a nice and elegant 'switch'
> statement.
>
> It turned out to have several limitations, ranging from ununderstood
> smartmatch magic to syntactical/semantical behavour problems.
>
> Trying to overcome these limitations by adding "when_str" and such
> destroys the "nice and elegant" part of given/when.

I suggest to add "when_str" and such, that means the usual "when"
semantic is still available for those who want to use it. (Although,
in my opinion, "when" should not be used and should probably be marked
with a huge warning / deprecation).

[Uri Guttman]

On 07/10/2012 03:13 PM, Klaus wrote:

> I suggest to add "when_str" and such, that means the usual "when"
> semantic is still available for those who want to use it. (Although,
> in my opinion, "when" should not be used and should probably be marked
> with a huge warning / deprecation).

rather than adding new keywords why not support a modifier or casting op
on when. something like when:str or when:num. that would force the item
to the desired context for smart matching in that when clause. i am sure
there are variant syntaxes other than modifiers.

uri

[Leon Timmermans]

On Tue, Jul 10, 2012 at 9:44 PM, Aaron Priven <aa...@priven.com> wrote:
> The question is whether a switch statement is useful. Does it make programs
> easier to write and easier to read? I think so. But the over-the-top DWIMery
> of smartmatch and when destroy that usefulness, by making it unclear what
> exactly is happening. Making the different types of "when" explicit rather
> than implicit makes the complexity apparent rather than papering it over.
> And that, in my opinion, is what is "nice and elegant".

Different kinds of when are not a solution. There's so much more to
matching than integers and strings, are we going to add a when keyword
for all of those?

Leon

[Johan Vromans]

Aaron Priven <aa...@priven.com> writes:

>> Perl did not have a 'switch' statement, and that was perceived to be
>> good since there were several other ways to obtain the same behaviour.
>
> Perceived by whom?

You must be new here.

> I pretty much disagree with every single thing you just wrote here.

Interesting, since ...

> But its perceived elegance comes at the cost of clarity.
> It looks simple when written down, but the hidden complexity is still
> there, and that hidden complexity makes it much, much harder to understand
> what it's doing, which means it's much, much harder to maintain.

> But the over-the-top DWIMery of smartmatch and when destroy that
> usefulness, by making it unclear what exactly is happening.

... we seem to have full agreement, until ...

> Making the different types of "when" explicit rather than implicit
> makes the complexity apparent rather than papering it over. And that,
> in my opinion, is what is "nice and elegant".

Your solution is to add more hooks and pins for the sole purpose of
being able to say "we have a switch statement".

My solution is to drop given/when/smartmatch, since it doesn't have the
advantages that were originally hoped for, and it's not necessary in the
first place.

-- Johan

[Brad Baxter]

On 7/9/12, Aaron Priven <aa...@priven.com> wrote:
> (I'm not endorsing any of the specific names of functions or operators used
> here, especially since I don't think builtins should have underlines in
> them. And note that ~> was proposed just the other day for a
> return-undef-not-an-exception ->.)

Okay, there's always

if ($x :> @values) { ... }

or

if ($x :-> @values) { ... }

which have the advantage of being smileys. :-)

Apologies if it sounds like I'm making light of the discussion, but
I'm infinitely more likely to use 'in' (et al) than 'when' or '~~'.

--
Brad

[Aaron Priven]

Lots of people want a switch statement even if you are not one of them. It is easier to follow and understand than the other ways of doing the same thing: ternary tables, long if/elseif sequences, dispatch tables, etc. Of course those other ways are possible. They just suck, at least some of the time.

On Tue, Jul 10, 2012 at 12:58 PM, Johan Vromans <jvro...@squirrel.nl> wrote:

Your solution is to add more hooks and pins for the sole purpose of

being able to say "we have a switch statement".

That is not my purpose. I believe a language with a switch statement -- even if there is more than one kind of conditional -- is more useful than one that isn't.

--
Aaron Priven, aa...@priven.com

[Aaron Priven]

On Tue, Jul 10, 2012 at 12:28 PM, Leon Timmermans <faw...@gmail.com> wrote:

Different kinds of when are not a solution.

Why not?

 

There's so much more to

matching than integers and strings, are we going to add a when keyword
for all of those?

The whole point of a switch statement is to make the common cases easier to handle. For uncommon cases, one has regular if/endif.

We're just taking that a step further, because perl has its operators decide what type is used rather than having typed data. Numeric and string matching are by far the most common types of comparison, so we create variants of when for them. For others, when_true can be used to provide a way to use other kinds of matching. Notably, regexp matching can be handled simply with when_true, because m/whatever/ already acts on $_ and returns a boolean result.

--
Aaron Priven, aa...@priven.com

[Aristotle Pagaltzis]

* Reverend Chip <rev....@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/>

[Rev. Chip]

On Wed, Jul 11, 2012 at 07:27:35AM +0200, Aristotle Pagaltzis wrote:
> Reverend Chip <rev....@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

[Aristotle Pagaltzis]

* Rev. Chip <rev....@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.

[Klaus]

I like the idea of a modifier (when:str, when:num, when:true).

How difficult would that be to be implemented (assuming that the
previously mentioned "in" operator for strings and its numerical
equivalent ("in_==" ?) would be available) ?

[Abigail]

On Tue, Jul 10, 2012 at 04:24:23PM -0700, Aaron Priven wrote:
> On Tue, Jul 10, 2012 at 12:28 PM, Leon Timmermans <faw...@gmail.com> wrote:
>
> > Different kinds of when are not a solution.
> >
>
> Why not?
>
>
> > There's so much more to
> > matching than integers and strings, are we going to add a when keyword
> > for all of those?
> >
>
> The whole point of a switch statement is to make the common cases easier to
> handle. For uncommon cases, one has regular if/endif.

Right. About all the cases I've wished for a switch statement are
of the form:

switch (expression yielding an integer) {
when (INT1) {do_something}
when (INT2) {do_something_else}
when (INT3 .. INT4) {# Expression falls in range
whatever
}
}

or

switch (expression yielding a string) {
when (STR1) {do_something}
when (STR2) {do_something_else}
when (STR3) {whatever}
}


with the former far more common than the latter; and half of the latter
cases could have trivially rewritten to dispatch on integers than on
strings.


I'm afraid the current given/when is a case of instead of solving the common
case, implementing a grand unified frame work that does it all. (A disease
most programmers have suffered from more than once, myself included (but
$WORK has worked hard to cure me from it, with some degree of success)).




Abigail

[Leon Timmermans]

On Wed, Jul 11, 2012 at 2:24 AM, Aaron Priven <aa...@priven.com> wrote:
> The whole point of a switch statement is to make the common cases easier to
> handle. For uncommon cases, one has regular if/endif.

I don't think that was the whole point at all. The point was that it
should DWIM, the problem is that it doesn't. And even if it was, your
common may not be my common. I use it most often to compare two lists
against each other, for example.

> We're just taking that a step further, because perl has its operators decide
> what type is used rather than having typed data. Numeric and string matching
> are by far the most common types of comparison, so we create variants of
> when for them. For others, when_true can be used to provide a way to use
> other kinds of matching. Notably, regexp matching can be handled simply with
> when_true, because m/whatever/ already acts on $_ and returns a boolean
> result.

«when_num 1» isn't much shorter than «when $_ == 1». If you want to be
explicit about it you already can.

Leon

[Brad Gilbert]

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

[Johan Vromans]

Abigail <abi...@abigail.be> writes:

> Right. About all the cases I've wished for a switch statement are
> of the form:
>
> switch (expression yielding an integer) {
> when (INT1) {do_something}
> when (INT2) {do_something_else}
> when (INT3 .. INT4) {# Expression falls in range
> whatever
> }
> }
>
> or
>
> switch (expression yielding a string) {
> when (STR1) {do_something}
> when (STR2) {do_something_else}
> when (STR3) {whatever}
> }

These two are precisely the raison d'être for switch.

Instead of ugly 'when_str' or "in_==" it would be much more elegant to
have something similar to:

given ( some expression : Num ) {

when (INT1) {do_something}
when (INT2) {do_something_else}
when (INT3 .. INT4) { # Expression falls in range

...
}
}

and

given ( expression : Str ) {

when (STR1) {do_something}
when (STR2) {do_something_else}
when (STR3) {whatever}
}

but preferrably something simple and elegant (and understandable, and
maintainable) aa:

switch ( expression : Str ) {
STR1: {do_something}
STR2: {do_something_else}
STR3: {whatever}
}

I even think that the :Str can be omitted if all match cases are
statically typed.

So, if we want switch, let's have switch.

-- Johan

[Jesse Luehrs]

On Wed, Jul 11, 2012 at 07:41:32PM +0200, Johan Vromans wrote:
> Abigail <abi...@abigail.be> writes:
>
> > Right. About all the cases I've wished for a switch statement are
> > of the form:
> >
> > switch (expression yielding an integer) {
> > when (INT1) {do_something}
> > when (INT2) {do_something_else}
> > when (INT3 .. INT4) {# Expression falls in range
> > whatever
> > }
> > }
> >
> > or
> >
> > switch (expression yielding a string) {
> > when (STR1) {do_something}
> > when (STR2) {do_something_else}
> > when (STR3) {whatever}
> > }
>

> These two are precisely the raison d'�tre for switch.

>
> Instead of ugly 'when_str' or "in_==" it would be much more elegant to
> have something similar to:
>
> given ( some expression : Num ) {
> when (INT1) {do_something}
> when (INT2) {do_something_else}
> when (INT3 .. INT4) { # Expression falls in range
> ...
> }
> }
>
> and
>
> given ( expression : Str ) {
> when (STR1) {do_something}
> when (STR2) {do_something_else}
> when (STR3) {whatever}
> }
>
> but preferrably something simple and elegant (and understandable, and
> maintainable) aa:
>
> switch ( expression : Str ) {
> STR1: {do_something}
> STR2: {do_something_else}
> STR3: {whatever}
> }
>
> I even think that the :Str can be omitted if all match cases are
> statically typed.
>
> So, if we want switch, let's have switch.

This is actually a really good point. If we were to enforce that all
cases in the switch statement were constants of the same type (all
strings, all numbers, etc), there wouldn't need to be any annotations
at all. Perhaps a new switch keyword that's entirely decoupled from
smartmatch is really what we want.

That said, I pretty rarely write long if-else chains comparing things
for equality (either numeric or stringy) in my own code, so I'm still
leaning toward the side of "maybe we don't need anything at all".

-doy

[Reverend Chip]

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.

[Aaron Priven]

I was wrong. A list of one element is still a list, so if we had in,
then $a in ($b) would be exactly equivalent to $a eq $b. Therefore, if
when_str takes a list rather than a scalar, then it can work just fine
to have

when_str ('a') { ...}
when_str ('b' , 'c', 'd') { ...}

as long as one defines when_str as using "in" rather than "eq", and
when_str does *not* use the reference syntax given below.

Yes I was.

Sorry about that

--
Aaron Priven, aa...@priven.com

[Father Chrysostomos via RT]

On Fri Jun 29 16:46:56 2012, rev....@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

[Aaron Priven]

On Wed, Jul 11, 2012 at 2:37 AM, Leon Timmermans <faw...@gmail.com> wrote:
> I don't think that was the whole point at all. The point was that it
> should DWIM, the problem is that it doesn't.

The point of *smartmatch* was to DWIM. And it doesn't work, because "X
matches Y" is too vague. Your what-I-mean may not be my what-I-mean,
and the rules built into smartmatch about what it should do with the
various types of X and Y are so complicated that it's impossible to
specify something clearly with it.

On the other hand, "The main reasons for using a switch include
improving clarity, by reducing otherwise repetitive coding, and (if
the heuristics permit) also offering the potential for faster
execution through easier compiler optimization in many cases," says
WIkipedia. It doesn't have anything to do with DWIM. So a given/when
that specifies an operator is still useful. If you could make a
smartmatch that really does DWIM, that would be better, but Perl tried
it twice (in 5.10.0 and 5.10.1) and it didn't work either time, and I
think it's probably impossible because WIM is too vague.

> And even if it was, your common may not be my common.

This is always going to be true, but that doesn't mean that we can't
figure out what's generally common and make those things easier to do.

> I use it most often to compare two lists against each other, for example.

Do you really use given/when for that, or do you mean you use ~~ for that?

I don't see how given could topicalize a list without making it
impossible to topicalize a reference to a list, or using a junction
object, but I think "(list) in (list)" could work.

> «when_num 1» isn't much shorter than «when $_ == 1». If you want to be
> explicit about it you already can.

I think we can have a shorter name than when_num, and I think it's
more expressive to be able to omit the topic variable.

On Wed, Jul 11, 2012 at 10:41 AM, Johan Vromans <jvro...@squirrel.nl> wrote:
> These two are precisely the raison d'être for switch.

>
> Instead of ugly 'when_str' or "in_=="

when_str and in_== are horrifically ugly names. Is it the names or the
concepts you object to?

> it would be much more elegant to have something similar to:
>
> given ( some expression : Num ) {

...

> given ( expression : Str ) {

...

> I even think that the :Str can be omitted if all match cases are
> statically typed.

I thought this was Perl, where we don't have data types.

From my perspective there's not that much difference between what
you've written here and something like "given_str" or "given_num".
Personally, I'd rather have the flexibility of having multiple whens
than multiple givens, but I certainly agree that what you've suggested
would take care of the most common cases.

On Wed, Jul 11, 2012 at 10:59 AM, Jesse Luehrs <d...@tozt.net> wrote:
> If we were to enforce that all
> cases in the switch statement were constants of the same type (all
> strings, all numbers, etc), there wouldn't need to be any annotations
> at all.

I could have sworn Perl data didn't have types.

> Perhaps a new switch keyword that's entirely decoupled from
> smartmatch is really what we want.

Yes, smartmatch and switch aren't necessarily lniked.

--
Aaron Priven, aa...@priven.com

[Rev. Chip]

On Wed, Jul 11, 2012 at 01:08:52PM -0700, Aaron Priven wrote:
> The point of *smartmatch* was to DWIM. And it doesn't work, because "X

> matches Y" is too vague. Your what-I-mean may not be my what-I-mean...

DWIM is not the problem. All language features are DWIM to some extent.
It's a matter of degree and quality.

For example, the rules for floating point numbers integrate +Inf, -Inf, +0,
-0, and NaN into operations like "==" and "<". This is DWIM in the same
manner as smart match, but obviously to a lesser degree, since the number of
special cases is lower and the results are simpler. The rules were
carefully thought out, and have served us all well.

Or when I ask for addition of two integers, I may mean to make an integer
and die on overflow if it doesn't fit, or I may mean to make a best effort
to represent the sum by converting to double. Perl's upconversion to double
is not forced by engineering, it's a DWIM judgment.

So, while I sympathize with complaints about ~~ having too many special
cases, it's not DWIM that's the problem. The problem, such as it is, is
that ~~ multiplexes too many behaviors into a single operator... often
without clues in the operands' syntax to distinguish among them.
--
Chip Salzenberg

[Rev. Chip]

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

[Rev. Chip]

On Tue, Jul 10, 2012 at 04:17:28PM -0700, Aaron Priven wrote:
> Lots of people want a switch statement ....

Fallacy: Argumentum ad populum.

Thirty million Frenchmen *can* be wrong.

> I believe a language with a switch statement -- even if there is more than
> one kind of conditional -- is more useful than one that isn't.

And yet your belief has not created in others any sense of obligation.
--
Chip Salzenberg

[Aaron Priven]

On Wed, Jul 11, 2012 at 3:40 PM, Rev. Chip <rev....@gmail.com> wrote:
> On Tue, Jul 10, 2012 at 04:17:28PM -0700, Aaron Priven wrote:
>> Lots of people want a switch statement ....
>
> Fallacy: Argumentum ad populum.

The context here was Mr. Vromans' comment that the lack of a switch
statement was "perceived to be a good thing." Obviously enough people
perceived otherwise to create Switch.pm and later given/when. My
statement was a response to his comment. It was not intended to be an
argument, in itself, in favor of switch.

I look forward to your reply to Mr. Vromans' message, responding to
his "You must be new here" with "Fallacy: Argumentum ad hominem."

>> I believe a language with a switch statement -- even if there is more than
>> one kind of conditional -- is more useful than one that isn't.
>
> And yet your belief has not created in others any sense of obligation.

Of course nobody should do anything based on what *I* believe. Again,
you omit the context. My sentence immediately before this was "That is
not my purpose." Mr. Vromans said: "Your solution is to add more hooks

and pins for the sole purpose of being able to say 'we have a switch

statement'." That is not my purpose and I felt I should correct it.

Is perl more useful with or without a better switch statement? What do
you think?

--
Aaron Priven, aa...@priven.com

[Rev. Chip]

On Wed, Jul 11, 2012 at 04:38:45PM -0700, Aaron Priven wrote:
> On Wed, Jul 11, 2012 at 3:40 PM, Rev. Chip <rev....@gmail.com> wrote:
> > On Tue, Jul 10, 2012 at 04:17:28PM -0700, Aaron Priven wrote:
> >> Lots of people want a switch statement ....
> >
> > Fallacy: Argumentum ad populum.
>
> The context here was Mr. Vromans' comment that the lack of a switch

> statement was "perceived to be a good thing." [...]

OK. Sorry about that.

> >> I believe a language with a switch statement -- even if there is more than
> >> one kind of conditional -- is more useful than one that isn't.
> >
> > And yet your belief has not created in others any sense of obligation.
>
> Of course nobody should do anything based on what *I* believe. Again,
> you omit the context. My sentence immediately before this was "That is
> not my purpose." Mr. Vromans said: "Your solution is to add more hooks
> and pins for the sole purpose of being able to say 'we have a switch
> statement'." That is not my purpose and I felt I should correct it.

Fair enough.

> Is perl more useful with or without a better switch statement? What do
> you think?

Since you ask: No, I think not. Switch is a fine idiom for equality tests
of numbers; sometimes strings. Everything else is fine as if/elsif/else.

Attempts to add switch to Perl are, at heart, cargo cult and/or envy.
"Everybody else has it, so we should have it," expresses what I hear.

Mostly I care about ~~. Switch can go away for all I care, or stay for all
I care. At least it's easy to read when others use it.

Incidentally, the current switch is syntax heavy for no reason. You often
type LESS if you choose the equivalent if/elsif/else chain. Dumb.
--
Chip Salzenberg

[Rev. Chip]

On Wed, Jul 11, 2012 at 07:48:04PM -0700, Rev. Chip wrote:
> On Wed, Jul 11, 2012 at 04:38:45PM -0700, Aaron Priven wrote:
> > Is perl more useful with or without a better switch statement? What do
> > you think?
>
> Since you ask: No, I think not. Switch is a fine idiom for equality tests
> of numbers; sometimes strings. Everything else is fine as if/elsif/else.

To clarify: I mean that generally in the field of languages, switches are
well suited to the problem domain of fanning out depending on specific
strings and numbers literally written. I'll even throw in a range check as
a nice-to-have, though C seems to get by just fine without ranges.

However: Switch in Perl doesn't make the cut. Perl is a rich language with
other approaches like regexes and arrays and hashes of coderefs. It also
has an explicit "elsif" keyword to make if/elsif/else chains easier to read.
Switches don't noticeably shorten code. And they are *barely* better at
expressing intent. Any programmer who, given an if/elsif/else chain,
doesn't *already* translate mentally to a switch-like fanout is so green we
shouldn't worry about his confusion. He'll learn.

So: Switch is not evil, but it doesn't pay its way. <trump>It's Fired.</trump>
--
Chip Salzenberg

[Jesse Luehrs]

On Wed, Jul 11, 2012 at 08:25:56PM -0700, Reverend Chip wrote:
> The way to improve a failed simplification is **NOT** to elaborate on
> it. Surely this should be self-evident. The fix is to take away, not add.

This I think is the main thing to take away from this entire thread.

-doy

[Rev. Chip]

On Wed, Jul 11, 2012 at 08:25:56PM -0700, Reverend Chip wrote:

> given $stuff { # simple variable needs no parens
> when 1 { print "one\n" }
> when "two" { print "two\n" }
> when 11..19 { print "teen" }
> when /[a-z]/ { print "contains lowercase\n" }
> }
>
> THIS I would probably use.

BTW, of course named constants would be allowed where literals are.
--
Chip Salzenberg

[Reverend Chip]

On 7/11/2012 2:14 AM, Klaus wrote:
> I like the idea of a modifier (when:str, when:num, when:true).

The way to improve a failed simplification is **NOT** to elaborate on
it. Surely this should be self-evident. The fix is to take away, not add.

How about sticking with smart match, as at present, but just removing
the required parentheses for cases where the syntax is simple enough?

given $stuff { # simple variable needs no parens
when 1 { print "one\n" }
when "two" { print "two\n" }
when 11..19 { print "teen" }
when /[a-z]/ { print "contains lowercase\n" }
}

... and everything else still requires the parens.

[Darin McBride]

On Wednesday July 11 2012 8:05:43 PM Rev. Chip wrote:
> On Wed, Jul 11, 2012 at 07:48:04PM -0700, Rev. Chip wrote:
> > On Wed, Jul 11, 2012 at 04:38:45PM -0700, Aaron Priven wrote:
> > > Is perl more useful with or without a better switch statement? What do
> > > you think?
> >
> > Since you ask: No, I think not. Switch is a fine idiom for equality tests
> > of numbers; sometimes strings. Everything else is fine as if/elsif/else.
>
> To clarify: I mean that generally in the field of languages, switches are
> well suited to the problem domain of fanning out depending on specific
> strings and numbers literally written. I'll even throw in a range check as
> a nice-to-have, though C seems to get by just fine without ranges.

I'd argue that C seems to get by just fine *despite* lack of ranges in its
switch statements. The number of times I've seen and/or written multiple case
statements for every number in a range... annoying.

case MAGIC_NUMBER:
case MAGIC_NUMBER + 1:
case MAGIC_NUMBER + 2:
case MAGIC_NUMBER + 3:
case MAGIC_NUMBER_END: /* I hope there's only 5 numbers in this range... */

And "specific strings": given that part of perl's background is shell, the
shell's switch-like statement should play a role here:

case `uname -r` in
2.4.*)
echo "Really too old"
exit 1
;;
2.6.*)
echo "Time to upgrade"
exit 2
;;
3.*)
echo "Modern!"
;;
esac

"strings [...] literally written"? Not so much. Mind you, since globs are
the natural "regular expression" of the shell, it seems reasonable that we use
regexes in our switch-like expressions.

> However: Switch in Perl doesn't make the cut. Perl is a rich language with
> other approaches like regexes and arrays and hashes of coderefs. It also

Hashes of coderefs work well with exact string matches. Not so well for
pretty much anything else. Sometimes, that works perfectly. But I end up
having to reach for if-elsif-else constructs often enough to see that's not
quite enough.

Sometimes I have arrays of match-to-coderefs where "match" can be a number of
possibilities. I've even had "match" be another code ref. But then I'm just
reimplementing given-when. In perl. And the syntax is not nearly so nice.

> has an explicit "elsif" keyword to make if/elsif/else chains easier to read.
> Switches don't noticeably shorten code. And they are *barely* better at
> expressing intent. Any programmer who, given an if/elsif/else chain,
> doesn't *already* translate mentally to a switch-like fanout is so green we
> shouldn't worry about his confusion. He'll learn.

Well, there goes my chance at a "senior perl developer"'s position. Because I
have to actually look at each clause in a long if-elsif-else chain to be sure
all of them are matching against the same key before I can mentally translate.
And that's time I'd rather not spend on it. Maybe I'm still too green.

With a given/when (or switch/case, case...in/...), whatever), I can generally
scan through the available matches quickly to find the value(s) I'm interested
in without having to worry too much about matches prior to it. (There is the
assumption here about the order of matches if they're not the C-style exact-
matching-only, but that's usually not much of an issue IME.)

Oh, and it reads more like English prose. And any time my code reads more
like prose than code, it's more likely that I didn't screw it up. Granted,
this means that the semantics underlying the syntax don't screw me up, but
that's kind of a different issue. "(Language) Implementation details." And
this is why I heavily use List::Util and List::MoreUtils. Not because they're
difficult to reimplement from core language features, but because my code reads
much closer to natural language.

In all this, my ideal would be to clean up the lexical-vs-local $_ issue, but
not lose either smart matching or given/when. If both of these could be
plugged into by CPAN modules, especially lexically, then we might see three or
four versions on CPAN that gain popularity and figure out how, if ever, to
transition (maybe put the most widely-accepted implementation into core, and
enable it with "use 5.20.0;" or whatever, while moving the current
implementation to another module so it's not necessarily loaded).

[Rev. Chip]

On Wed, Jul 11, 2012 at 10:00:48PM -0600, Darin McBride wrote:
> > To clarify: I mean that generally in the field of languages, switches are
> > well suited to the problem domain of fanning out depending on specific
> > strings and numbers literally written. I'll even throw in a range check as
> > a nice-to-have, though C seems to get by just fine without ranges.
>
> I'd argue that C seems to get by just fine *despite* lack of ranges in its
> switch statements.

Tomato, tomahto ... C gets by. Perhaps it's because the ranges end up being
taken out of the switches.

> And "specific strings": given that part of perl's background is shell, the
> shell's switch-like statement should play a role here:
>
> case `uname -r` in
> 2.4.*)
> echo "Really too old"
> exit 1
> ;;

> [...]
> esac

This is a very good example; I should have thought of it. For strings,
then, pattern matching is a prime use case. Analogous to numeric ranges,
perhaps?

> Sometimes I have arrays of match-to-coderefs where "match" can be a number of
> possibilities. I've even had "match" be another code ref. But then I'm just
> reimplementing given-when. In perl. And the syntax is not nearly so nice.

I see what you're saying, but the dynamic construction is often itself a
feature, isn't it? Not the killer argument here.

> > Any programmer who, given an if/elsif/else chain, doesn't *already*
> > translate mentally to a switch-like fanout is so green we shouldn't
> > worry about his confusion. He'll learn.
>
> Well, there goes my chance at a "senior perl developer"'s position. Because I
> have to actually look at each clause in a long if-elsif-else chain to be sure
> all of them are matching against the same key before I can mentally translate.
> And that's time I'd rather not spend on it. Maybe I'm still too green.

People vary as to what patterns are obvious to them. I can't read Haskell
without my eyes crossing, for example, and I'll never find Python code
obvious ... too few syntactic handholds. But in Perl, I simply have *never*
had any working programmer, using Perl, actually find the lack of switch a
problem for writing nor for reading. Never.

> Oh, and it reads more like English prose. And any time my code reads more
> like prose than code, it's more likely that I didn't screw it up.

I think you're projecting here a language that doesn't really exist. Perl
isn't COBOL; it only "reads" like English in abstract and specific ways.
The myth of "reads like English" leads to bad design. It borrows certain
very specific English grammar, in some limited and specific cases. More
English is not better per se.

> In all this, my ideal would be to clean up the lexical-vs-local $_ issue, but
> not lose either smart matching or given/when.

Strangely enough, I agree with this. I don't want given/when to strictly
keep their current verbose and (to my mind) unhelpful forms, but mostly what
I *really* don't want is for weak arguments and myths to rule design.
--
Chip Salzenberg

[Chip Salzenberg]

On Wed, Jul 11, 2012 at 11:21 PM, Rev. Chip <rev....@gmail.com> wrote:

> In all this, my ideal would be to clean up the lexical-vs-local $_ issue, but
> not lose either smart matching or given/when.

Strangely enough, I agree with this.

Well, kind of.  If given/when were deprecated or vastly trimmed back I wouldn't argue at all. I care about how the decision is made, more than the decision.

[Aristotle Pagaltzis]

* Rev. Chip <rev....@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.

[Nicholas Clark]

On Wed, Jul 11, 2012 at 10:00:48PM -0600, Darin McBride wrote:

> On Wednesday July 11 2012 8:05:43 PM Rev. Chip wrote:

> > Switches don't noticeably shorten code. And they are *barely* better at
> > expressing intent. Any programmer who, given an if/elsif/else chain,
> > doesn't *already* translate mentally to a switch-like fanout is so green we
> > shouldn't worry about his confusion. He'll learn.
>
> Well, there goes my chance at a "senior perl developer"'s position. Because I
> have to actually look at each clause in a long if-elsif-else chain to be sure
> all of them are matching against the same key before I can mentally translate.
> And that's time I'd rather not spend on it. Maybe I'm still too green.

Two very good points, I think.

Nicholas Clark

[Leon Timmermans]

On Wed, Jul 11, 2012 at 11:08 PM, Aaron Priven <aa...@priven.com> wrote:
>> «when_num 1» isn't much shorter than «when $_ == 1». If you want to be
>> explicit about it you already can.
>
> I think we can have a shorter name than when_num, and I think it's
> more expressive to be able to omit the topic variable.

Fair enough. I'd probably just use numwise from Smart::Match,
something like «when any(numwise(1, 2, 4))» if I wanted to play that
safe.

Leon

[demerphq]

On 10 July 2012 20:56, Nicholas Clark <ni...@ccl4.org> wrote:
> On Tue, Jul 10, 2012 at 11:44:19AM -0700, Aaron Priven wrote:
>
>> The question is whether a switch statement is useful. Does it make programs
>> easier to write and easier to read? I think so. But the over-the-top
>> DWIMery of smartmatch and when destroy that usefulness, by making it
>> unclear what exactly is happening. Making the different types of "when"
>> explicit rather than implicit makes the complexity apparent rather than
>> papering it over. And that, in my opinion, is what is "nice and elegant".
>
> But I can achieve the same with a chained sequence of
> if()/elsif()/elsif()/else
>
> And within the condition blocks I can be explicit about the "when".
>
> And that uses less total syntax than the proposal for distinct "when"
> operators.
>
> And that makes the language easier to learn, and maintain (which is a benefit)
> at a cost (less expressiveness). It's all a question of trade off.

To me switch in C was essentially a feature designed to offload
optimization onto the developer. IOW, had C had a really really
powerful optimizer maybe it would have optimized if statements into
the same kind of control structure used by switch. However space was
limited meaning such a good optimizer was not available, thus it was
easier to provide a way that the programmer could write the code in a
such a way that the compiler could easily implement the optimization.

Assuming this hypothesis is correct, and I have no idea - it just
makes sense to me, then we have really screwed the pooch with our
switch implementation. Not only do we not have an optimizer smart
enough to convert a chained if into a more efficient structure we
managed to produce a switch which cant be optimized in a similar way
either.

What point is there in using switch if you can implement the same
thing faster with a hash lookup into a table of closures?

cheers,
Yves







--
perl -Mre=debug -e "/just|another|perl|hacker/"

[Aristotle Pagaltzis]

* demerphq <deme...@gmail.com> [2012-07-12 14:20]:

> To me switch in C was essentially a feature designed to offload
> optimization onto the developer. IOW, had C had a really really
> powerful optimizer maybe it would have optimized if statements into
> the same kind of control structure used by switch. However space was
> limited meaning such a good optimizer was not available, thus it was
> easier to provide a way that the programmer could write the code in a
> such a way that the compiler could easily implement the optimization.

I wouldn’t put money on that hypothesis.

Mine would be that compiler implementation probably drove language
design: a switch like the one that C has is very simple to do on the
machine code level *and* easy to expose in the language in a way that
seems to fit in, so at some point during the evolution of the language
(which was after all heavily informed by attempting to implement) it
presumably just seemed an obvious thing to put into the language.

In short, my bet money is on simple inertia.

> Assuming this hypothesis is correct, and I have no idea - it just
> makes sense to me, then we have really screwed the pooch with our
> switch implementation. Not only do we not have an optimizer smart
> enough to convert a chained if into a more efficient structure we
> managed to produce a switch which cant be optimized in a similar way
> either.

That is by design. Larry never added anything switchish in Perl 5
because he disliked the expressiveness of the existing switchoids
in other languages. He went about fixing that only in Perl 6… and
that design was then copypasted wholesale into Perl 5 with minimal
adjustments even though many of the premises it rests on are those
points where Perl 6 departs radically from those assumed by Perl 5.
That was the cause of all the problems with it. But its core design
(a block akin to a one-shoot loop, combined with a special form of
`if` that implictly does a `last` on your behalf after its body) is
sound. It means you can intersperse code to run among the branches
unconditionally, up to the first matching branch, so you can write
some very complex control flows very DRY yet clearly and readably.

> What point is there in using switch if you can implement the same
> thing faster with a hash lookup into a table of closures?

Dunno. Why implement closures when you can do the same thing faster
with bare function pointers and passed-around structs? :-)

[demerphq]

I have a reply from Larry on Perlmonks that ISTR says something
different. Ill try to dig it up.

[Aristotle Pagaltzis]

* demerphq <deme...@gmail.com> [2012-07-12 15:55]:

Please do. I would love to see that.

[Aaron Crane]

Aristotle Pagaltzis <paga...@gmx.de> wrote:
> * demerphq <deme...@gmail.com> [2012-07-12 14:20]:
>> To me switch in C was essentially a feature designed to offload
>> optimization onto the developer.
>

> I wouldn’t put money on that hypothesis.
>
> Mine would be that compiler implementation probably drove language
> design: a switch like the one that C has is very simple to do on the
> machine code level *and* easy to expose in the language in a way that
> seems to fit in, so at some point during the evolution of the language
> (which was after all heavily informed by attempting to implement) it
> presumably just seemed an obvious thing to put into the language.
>
> In short, my bet money is on simple inertia.

FWIW, a C-like switch construct was present in B, C's immediate
ancestor, with the same spelling as used in C. The users' reference
manual describes it as "the most complicated statement in B". In
addition, a compiler diagnostic ">c" is glossed as "case table
overflow (fatal)", which I assume is relevant.

http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html
http://cm.bell-labs.com/cm/cs/who/dmr/btut.html
http://cm.bell-labs.com/cm/cs/who/dmr/bintro.html

An almost identical construct was also present in BCPL, the
inspiration for B. According to the reference manual pp 22–23:

6.17 Switchon Commands

Syntactic form: switchon E into <block>
where the block contains labels of the form:
case <constant>:
or
default:

Semantics: The expression is first evaluated, then if a case
exists which has a constant with the same value
then execution is resumed at that label; otherwise
if there is a default label then execution is
continued from there; otherwise execution is
resumed just after the end of the switchon
command.

The switch is implemented as a direct switch, a
sequential search or a hash switch depending on
the number and range of the case constants.

http://www.fh-jena.de/~kleine/history/languages/Richards-BCPL-ReferenceManual.pdf

The last sentence suggests that using switchon rather than chained
conditions allowed the BCPL programmer to delegate selection of a
specific implementation to the compiler's optimiser.

I also note that the predecessor of BCPL was CPL. I can't easily find
a description of CPL, but it was heavily influenced by Algol-60, which
had a construct named "switch" and also intended for doing multi-way
switches, but rather different in style. (Effectively, you declare an
array of labels, and use an integral expression to index that array.)
AFAICT, Algol-60's predecessor Algol-58 had no switch statement.

--
Aaron Crane ** http://aaroncrane.co.uk/

[Aristotle Pagaltzis]

* Aaron Crane <pe...@aaroncrane.co.uk> [2012-07-12 18:00]:

> FWIW, a C-like switch construct was present in B, C's immediate

> ancestor, with the same spelling as used in C. […]

Ah, the resident historian speaks. :-)

> The last sentence suggests that using switchon rather than chained
> conditions allowed the BCPL programmer to delegate selection of
> a specific implementation to the compiler's optimiser.

Sort of the opposite of Yves’ hypothesis in a sense…

The question is, of course, what exactly was the thinking that got it
into those earlier languages. Was it more what I hypothesised, an
obvious-seeming way to expose an underlying optimisation? Or more like
Yves’ hypothesis that it was a workaround around a perceived/felt lack
of resources? Or maybe the truth was in-between.