map {chop; $_} (Literals problem) #2079

p5pRT · 2000-06-12T00:49:11Z

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

Searchable as RT3365$

p5pRT · 2000-06-12T00:49:11Z

From pdcawley@rt158.private.realtime.co.uk

Created by @pdcawley

So, I'm trying to install Coy.pm under perl 5.6.0 and it throws an
error, so I investigate. It seems that the following script:

$ /usr/local/bin/perl5.6.0 -le 'print map {chop; $_} (Word)'

throws a 'Modification of a read-only value attempted at -e line 1'
if you run it under perl5.6.0. Which kind of makes sense, but:

$ /usr/bin/perl5.00503 -le 'print map {chop; $_} (Word)'

happily prints out:

Wor

One of these behaviours is presumably a bug...

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.0:

Configured by pdcawley at Fri May 12 13:45:35 BST 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.14-15mdk, archname=i686-linux
    uname='linux rt158.private.realtime.co.uk 2.2.14-15mdk #1 tue jan 4 22:24:20 cet 2000 i686 unknown '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.95.2 19991024 (release)
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.1.2.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/local/lib/perl5/5.6.0/i686-linux/CORE'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /usr/local/lib/perl5/5.6.0/i686-linux
    /usr/local/lib/perl5/5.6.0
    /usr/local/lib/perl5/site_perl/5.6.0/i686-linux
    /usr/local/lib/perl5/site_perl/5.6.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.6.0:
    HOME=/home/pdcawley
    LANG=en
    LANGUAGE=en
    LC_ALL=en_GB
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/pdcawley/bin:/opt/IBMJava2-13/bin:/usr/local/bin:/bin:/usr/bin::/usr/X11R6/bin:/usr/games:/usr/X11R6/bin:/usr/games:/usr/X11R6/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2000-06-12T05:39:33Z

From [Unknown Contact. See original ticket]

pdcawley@rt158.private.realtime.co.uk writes:

So, I'm trying to install Coy.pm under perl 5.6.0 and it throws an
error, so I investigate. It seems that the following script:

$ /usr/local/bin/perl5.6.0 -le 'print map {chop; $_} (Word)'

throws a 'Modification of a read-only value attempted at -e line 1'
if you run it under perl5.6.0. Which kind of makes sense, but:

$ /usr/bin/perl5.00503 -le 'print map {chop; $_} (Word)'

happily prints out:

Wor

One of these behaviours is presumably a bug...

perlfunc.pod (on grep and map) says quite clearly that $_ is a
*reference*
to the values in the list. "[Modifying the elements of the array] can
cause bizarre results if the LIST is not a named array."

Try this with perl5.00503:

for( my $i=1; $i <=2; $i++ ){
print map {chop; $_} ('Word');
}

Note that
print map {chop; $_} (qw(Word))
gives the "expected" result with 5.00503 but is also a run-time error
with perl5.6.0.

No run-time error (but a somewhat counter-intuitive result) is produced
by:
#! /usr/bin/perl -w
use strict;
my $w = 'Word';
print map {chop;�$_} ( $w, $w, $w );
print "\nWhat have they done to my $w?\n";

Cheers,
-Wolfgang

p5pRT · 2000-06-12T06:56:08Z

From [Unknown Contact. See original ticket]

Wolfgang Laun <Wolfgang.Laun@alcatel.at> wrote

perlfunc.pod (on grep and map) says quite clearly that $_ is a
*reference*
to the values in the list.

... which is somewhat misleading, not to say plain wrong. $_ is an
alias, not a reference.

                       "\[Modifying the elements of the array\] can
cause bizarre results if the LIST is not a named array."

I've never understood this "named array" business. Surely an
unnamed array (e.g. @$aref ) or a list of scalar variables is just as
respectable?

Patch for perl-current attached.

Mike Guy

Inline Patch

--- ./pod/perlfunc.pod.orig	Tue May 30 15:02:58 2000
+++ ./pod/perlfunc.pod	Mon Jun 12 14:47:54 2000
@@ -2078,9 +2078,9 @@
 
     @foo = grep {!/^#/} @bar;    # weed out comments
 
-Note that, because C<$_> is a reference into the list value, it can
-be used to modify the elements of the array.  While this is useful and
-supported, it can cause bizarre results if the LIST is not a named array.
+Note that C<$_> is an alias to the list value, so it can be used to
+modify the elements of the LIST.  While this is useful and supported,
+it can cause bizarre results if the elements of LIST are not variables.
 Similarly, grep returns aliases into the original list, much as a for
 loop's index variable aliases the list elements.  That is, modifying an
 element of a list returned by grep (for example, in a C<foreach>, C<map>
@@ -2462,9 +2462,9 @@
 	$hash{getkey($_)} = $_;
     }
 
-Note that, because C<$_> is a reference into the list value, it can
-be used to modify the elements of the array.  While this is useful and
-supported, it can cause bizarre results if the LIST is not a named array.
+Note that C<$_> is an alias to the list value, so it can be used to
+modify the elements of the LIST.  While this is useful and supported,
+it can cause bizarre results if the elements of LIST are not variables.
 Using a regular C<foreach> loop for this purpose would be clearer in
 most cases.  See also L</grep> for an array composed of those items of
 the original list for which the BLOCK or EXPR evaluates to true.

End of patch

p5pRT · 2000-06-12T07:51:05Z

From [Unknown Contact. See original ticket]

mjtg@cus.cam.ac.uk wrote:

Wolfgang Laun <Wolfgang.Laun@alcatel.at> wrote

perlfunc.pod (on grep and map) says quite clearly that $_ is a *reference*
to the values in the list.

... which is somewhat misleading, not to say plain wrong. $_ is an
alias, not a reference.

Since I did not write that in the first place I have no heart in defending it.
FORTRANers might call it a "(dynamic) equivalence", and in CHILL
it is actually called "location identity". Personally, I feel that "alias"
(or "equivalence" or "identity") are closer to some intuitive understanding
while "reference" is referring to implementation techniques. Whatever.

                       "\[Modifying the elements of the array\] can
cause bizarre results if the LIST is not a named array."
I've never understood this "named array" business. Surely an
unnamed array (e.g. @$aref ) or a list of scalar variables is just as
respectable?

Did you run the code snippet at the end of my 1st mail?

#! /usr/bin/perl -w
use strict;
my $w = 'Word';
print map {chop;�$_} ( $w, $w, $w );
print "\nWhat have they done to my $w?\n";

Surely this is "a list of scalar variables". So, to be on the safe side, the list itself
ought to be a variable, rather than the elements of the list. (You
might consider updating your patch.)

Thank you,
-Wolfgang

p5pRT · 2000-06-12T07:58:29Z

From @tamias

On Mon, Jun 12, 2000 at 04:51:51PM +0200, Wolfgang Laun wrote:

mjtg@cus.cam.ac.uk wrote:
Wolfgang Laun <Wolfgang.Laun@alcatel.at> wrote
                       "\[Modifying the elements of the array\] can
cause bizarre results if the LIST is not a named array."
I've never understood this "named array" business. Surely an
unnamed array (e.g. @$aref ) or a list of scalar variables is just as
respectable?
Did you run the code snippet at the end of my 1st mail?

#! /usr/bin/perl -w
use strict;
my $w = 'Word';
print map {chop;$_} ( $w, $w, $w );
print "\nWhat have they done to my $w?\n";

Surely this is "a list of scalar variables". So, to be on the safe side,
the list itself ought to be a variable, rather than the elements of the
list. (You might consider updating your patch.)

I wouldn't call those results bizarre. Those are exactly the results you
would get with:

my $w = 'Word';
chop $w;
print $w;
chop $w;
print $w
chop $w;
print $w;

(BTW, you had a control character in the middle of your code snippet.)

Ronald

p5pRT · 2000-06-12T08:18:07Z

From [Unknown Contact. See original ticket]

*********** REPLY SEPARATOR ***********

On 12.06.00 at 10:58 Ronald J Kimball wrote:

On Mon, Jun 12, 2000 at 04:51:51PM +0200, Wolfgang Laun wrote:
mjtg@cus.cam.ac.uk wrote:
Wolfgang Laun <Wolfgang.Laun@alcatel.at> wrote
                       "\[Modifying the elements of the array\] can
cause bizarre results if the LIST is not a named array."
I've never understood this "named array" business. Surely an
unnamed array (e.g. @$aref ) or a list of scalar variables is just as
respectable?
Did you run the code snippet at the end of my 1st mail?

#! /usr/bin/perl -w
use strict;
my $w = 'Word';
print map {chop;$_} ( $w, $w, $w );
print "\nWhat have they done to my $w?\n";

Surely this is "a list of scalar variables". So, to be on the safe side,
the list itself ought to be a variable, rather than the elements of the
list. (You might consider updating your patch.)
I wouldn't call those results bizarre...

I'm not aware that I called them "bizarre" (I did NOT write perlfunc.pod). In my mail I was
merely using "counter-intuitive", since having (scalar!) references sneak into the construction
of a literal list value may be somewhat surprising.

... Those are exactly the results you
would get with:

my $w = 'Word';
chop $w;
print $w;
chop $w;
print $w
chop $w;
print $w;

Well, did you see that before you ran the code? If so: how did you acquire that insight in the first place?

(BTW, you had a control character in the middle of your code snippet.)

Cut and paste on Windows 98 - which I don't normally use.

Ronald

Cheers,
-Wolfgang

p5pRT · 2003-05-02T21:53:21Z

From @iabyn

(Just reviewing old bugs)

SInce the docs have been updated to reflect reality, I guess this call
can be closed.

Dave M.

p5pRT · 2003-05-02T21:53:22Z

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

p5pRT closed this as completed May 2, 2003

p5pRT added Severity Low distro-Linux type-library labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

map {chop; $_} (Literals problem) #2079

map {chop; $_} (Literals problem) #2079

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

p5pRT commented May 2, 2003

p5pRT commented May 2, 2003

map {chop; $_} (Literals problem) #2079

map {chop; $_} (Literals problem) #2079

Comments

p5pRT commented Jun 12, 2000

p5pRT commented Jun 12, 2000

From pdcawley@rt158.private.realtime.co.uk

Created by @pdcawley

p5pRT commented Jun 12, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jun 12, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jun 12, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jun 12, 2000

From @tamias

p5pRT commented Jun 12, 2000

From [Unknown Contact. See original ticket]

p5pRT commented May 2, 2003

From @iabyn

p5pRT commented May 2, 2003