Skip Menu |
 
Report information
Id: 68312
Status: rejected
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: iang <ian.goodacre [at] xtra.co.nz>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type:
  • docs
  • Patch
Perl Version: (no value)
Fixed In: (no value)

Attachments
0001-Clarified-description-of-the-assignment-operator.patch
0001-Revised-assignment-operator-docs.patch



Subject: perlop / list assignment documentation
Date: Sat, 08 Aug 2009 11:32:31 +1200
To: perlbug [...] perl.org
From: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
Download (untitled) / with headers
text/plain 3.1k
This is a bug report for perl from ian@alula.local, generated with the help of perlbug 1.39 running under perl 5.11.0. ----------------------------------------------------------------- [Please describe your issue here] Here is a patch to perlop.pod which, I think, clarifies the description of the assignment operator a little. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=docs severity=low --- Site configuration information for perl 5.11.0: Configured by ian at Sun Mar 29 08:00:08 NZDT 2009. Summary of my perl5 (revision 5 version 11 subversion 0) configuration: Commit id: Platform: osname=linux, osvers=2.6.18-92.el5, archname=i686-linux uname='linux alula.local 2.6.18-92.el5 #1 smp tue jun 10 18:49:47 edt 2008 i686 i686 i386 gnulinux ' config_args='-DDEBUGGING' hint=previous, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='4.1.2 20071124 (Red Hat 4.1.2-42)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 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, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -g -L/usr/local/lib -fstack-protector' Locally applied patches: PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */ PERL_GIT_UNCOMMITTED_CHANGES /* do not remove this line */ --- @INC for perl 5.11.0: /home/ian/localperl/lib/site_perl/5.11.0/i686-linux /home/ian/localperl/lib/site_perl/5.11.0 /home/ian/localperl/lib/5.11.0/i686-linux /home/ian/localperl/lib/5.11.0 . --- Environment for perl 5.11.0: HOME=/home/ian LANG=en_NZ.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/java/jdk/bin:/usr/local/java/ant/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/Trolltech/Qt-4.4.3/bin:/home/ian/bin:/sbin PERLDOC_PAGER=less PERL_BADLANG (unset) SHELL=/bin/bash
From 165a188b1d79244c58e9ed0d4be753b6ee674f7d Mon Sep 17 00:00:00 2001 From: Ian Goodacre <Ian.Goodacre@xtra.co.nz> Date: Sat, 8 Aug 2009 11:10:17 +1200 Subject: [PATCH] Clarified description of the assignment operator. --- pod/perlop.pod | 27 ++++++++++++++++++++------- 1 files changed, 20 insertions(+), 7 deletions(-) diff --git a/pod/perlop.pod b/pod/perlop.pod index e677430..b9ec357 100644 --- a/pod/perlop.pod +++ b/pod/perlop.pod @@ -731,7 +731,12 @@ X<%=> X<^=> X<x=> "=" is the ordinary assignment operator. -Assignment operators work as in C. That is, +There are two forms of the assignment operator: scalar assignment and list +assignment. + +If the left operand is a scalar lvalue then the assignment operator +is a scalar assignment operator. Scalar assignment operators work +as in C. That is, $a += 2; @@ -740,8 +745,8 @@ is equivalent to $a = $a + 2; although without duplicating any side effects that dereferencing the lvalue -might trigger, such as from tie(). Other assignment operators work similarly. -The following are recognized: +might trigger, such as from tie(). Other scalar assignment operators work +similarly. The following are recognized: **= += *= &= <<= &&= -= /= |= >>= ||= @@ -767,10 +772,18 @@ is equivalent to $a += 2; $a *= 3; -Similarly, a list assignment in list context produces the list of -lvalues assigned to, and a list assignment in scalar context returns -the number of elements produced by the expression on the right hand -side of the assignment. +If the left operand of the assignment operator is a list then the operator +is a list assignment operator. In this case, each element of the list +must be an lvalue or C<undef>. The right operand is evaluated in list context +and elements of the resulting list are assigned to elements of the list on the +left hand side. See L<List value constructors> in L<perldata> for examples. + +In scalar context, the list assignment operator returns the number of +elements produced by the expression on the right hand side of the +assignment. + +In list context, the list assignment operator returns the list of +lvalues assigned to. =head2 Comma Operator X<comma> X<operator, comma> X<,> -- 1.6.1
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Sat, 08 Aug 2009 19:19:16 +0200
To: perl5-porters [...] perl.org
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 761b
"ian.goodacre@xtra.co.nz (via RT)" <perlbug-followup@perl.org> writes: Show quoted text
> +If the left operand of the assignment operator is a list then the operator
Please don't call the left operand a "list". That is not just misleading, but also risks propagating rather tough misconceptions. Consider: "is an array, a hash, a slice, or enclosed in parentheses". Consider: In the following, is f a list? a scalar? both? use 5.010; use strict; use warnings; my $x=1; my $y=2; sub f () :lvalue { $x, $y } say f; f=4; say f; f=(5,6); say f __END__ Useless use of a constant in void context at - line 12. 12 14 16 Eirik -- Flon's Law: There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Sat, 08 Aug 2009 19:28:18 +0200
To: perl5-porters [...] perl.org
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 655b
Eirik Berg Hanssen <Eirik-Berg.Hanssen@allverden.no> writes: Show quoted text
> Consider: In the following, is f a list? a scalar? both? > > use 5.010; > use strict; > use warnings; > my $x=1; > my $y=2; > sub f () :lvalue { > $x, $y > } > say f; > f=4; > say f; > f=(5,6); > say f > __END__ > Useless use of a constant in void context at - line 12. > 12 > 14 > 16
Come to think of it, I could do that one even clearer: use 5.010; use strict; use warnings; my $x=1; my $y=2; sub f () :lvalue { $x, $y } say f; say f=4; say f; say f=(5,6); say f; __END__ Useless use of a constant in void context at - line 12. 12 4 14 6 16 Eirik -- Ceci n'est pas une .sig.
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 00:44:36 +1200
To: perlbug-followup [...] perl.org
From: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
Download (untitled) / with headers
text/plain 2.7k
Eirik Berg Hanssen via RT wrote: Show quoted text
> "ian.goodacre@xtra.co.nz (via RT)" <perlbug-followup@perl.org> writes: > >
>> +If the left operand of the assignment operator is a list then the operator >>
> > Please don't call the left operand a "list". That is not just > misleading, but also risks propagating rather tough misconceptions. > > Consider: "is an array, a hash, a slice, or enclosed in parentheses". > > Consider: In the following, is f a list? a scalar? both? > > use 5.010; > use strict; > use warnings; > my $x=1; > my $y=2; > sub f () :lvalue { > $x, $y > } > say f; > f=4; > say f; > f=(5,6); > say f > __END__ > Useless use of a constant in void context at - line 12. > 12 > 14 > 16 > > > Eirik >
Despite having submitted the patch, because I think the description should be improved, I don't know enough to decide how to describe the assignment operator. I would be happy to submit a revised patch incorporating your (Eirik's) suggestion if that helps. I think it is a significant improvement over what I wrote (Eirik++). I would also be happy, and not at all offended, if someone wrote something entirely different and more correct. I was motivated primarily because the terms "list assignment" and "scalar assignment" are used without being defined. Any revision which accurately defines them would be great. I am curious why you (Eirik) say "enclosed in parentheses" rather than "a list". This, no doubt, results from my abiding confusion as to whether or when parentheses enclosing an expression constitutes a list and when they are merely affecting precedence or make no difference at all. Are there cases where a list as a left operand would not cause the assignment to be a list assignment? Are there cases where a left operand being enclosed in parentheses would not be a list? I would be very interested to see example, to help my learning. I am uncertain whether it makes more sense to say that the assignment operator provides context to its left operand or its left operand provides context to the assignment operator. In the statement 'f=(5,6);', it appears that both operands are evaluated in scalar context. Yet it doesn't make much sense to me to say that the assignment operator provides scalar context to its left operand given that the assignment operator is a scalar or list assignment operator depending on the nature of its left operand - i.e. the left operand seems to determine the nature of the assignment operator, not vice-versa. In the statement '($x,$y)=(5,6);' the left operand is not evaluated in scalar context (in which case it would not be a list and we would have scalar assignment of 6 to $y with $x and 5 being evaluated in void context). I am very confused. Regards, Ian Goodacre
CC: perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Mon, 10 Aug 2009 10:12:06 -0500
To: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 2.9k
On Mon, Aug 10, 2009 at 7:44 AM, Ian Goodacre<Ian.Goodacre@xtra.co.nz> Show quoted text
> I am curious why you (Eirik) say "enclosed in parentheses" rather than "a > list".
As I understand it, there is a weak taboo against calling an "array" data structure a "list" because "list" is supposed to be strictly about syntax. I do not agree with this convention myself and often break it because I think "list" is a perfectly fine word for an ordered collection. That's one of the hiss-fights you've stepped into. Show quoted text
> This, no doubt, results from my abiding confusion as to whether or > when parentheses enclosing an expression constitutes a list and when they > are merely affecting precedence or make no difference at all. Are there > cases where a list as a left operand would not cause the assignment to be a > list assignment? Are there cases where a left operand being enclosed in > parentheses would not be a list? I would be very interested to see example, > to help my learning.
Me too. I think a chart of various examples and what happens with them would be very much in order near the assignment operator. Show quoted text
> I am uncertain whether it makes more sense to say that the assignment > operator provides context to its left operand or its left operand provides > context to the assignment operator. In the statement 'f=(5,6);', it appears > that both operands are evaluated in scalar context.
lvalue subroutines are always scalar. "list" syntax, in scalar context, causes the commas to be interpreted as "the comma operator" rather than the "list element separator operator." Fat arrows, too. catnip:~# perl -wle 'my $x = (5,6); print $x' Useless use of a constant in void context at -e line 1. 6 catnip:~# perl -wle 'my $x = @y = (5,6); print $x' Name "main::y" used only once: possible typo at -e line 1. 2 In the first, the list is parsed as a list. In the second, the list is parsed as an array. Show quoted text
> Yet it doesn't make much > sense to me to say that the assignment operator provides scalar context to > its left operand given that the assignment operator is a scalar or list > assignment operator depending on the nature of its left operand - i.e. the > left operand seems to determine the nature of the assignment operator, not > vice-versa. In the statement '($x,$y)=(5,6);' the left operand is not > evaluated in scalar context (in which case it would not be a list and we > would have scalar assignment of 6 to $y with $x and 5 being evaluated in > void context). I am very confused.
Context is provided by the left side of an assignment. lvalue subroutines when used as lvalues are always scalar. As l-values, parentheses make lists. As r-values, they make lists in list context or guide precedence in scalar context. This can be confusing: catnip:~# perl -wle 'my $x = () = (5,6); print $x' 2 We might say that the empty list is parsed as an array, then evaluated in scalar context. Show quoted text
> Regards, > Ian Goodacre >
-- Today in 1680 Taos besieged Santa Fe http://www.amazon.com/exec/obidos/ISBN=1574160648/tipjartransactioA
CC: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Mon, 10 Aug 2009 18:20:52 +0200
To: David Nicol <davidnicol [...] gmail.com>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 3.7k
David Nicol <davidnicol@gmail.com> writes: Show quoted text
> On Mon, Aug 10, 2009 at 7:44 AM, Ian Goodacre<Ian.Goodacre@xtra.co.nz> >
>> I am curious why you (Eirik) say "enclosed in parentheses" rather than "a >> list".
Because parentheses do not make a list, except in a certain interpretation of the left hand operand of either the assignment operator or the (in list context) repetition operator. Nowhere else. (Unless I'm forgetting yet another special case.) Show quoted text
> lvalue subroutines are always scalar.
Really now? use 5.010; use strict; use warnings; my $x=1; my $y=2; sub f () :lvalue { $x, $y } say f; say( (f)=(4) ); say( (f).(4) ); say f; say( (f)=(5,6) ); say( (f).(5,6) ); say f; __END__ Useless use of a constant in void context at - line 14. Use of uninitialized value in say at - line 10. Use of uninitialized value in concatenation (.) or string at - line 11. Use of uninitialized value in say at - line 12. 12 4 4 4 56 66 56 Not only does say() evaluate f in list context, list assignment does too! (When, as here, the left operand of the assignment operator is enclosed in parentheses, it is a list assignment.) In a nutshell: The lvalueness of f does not determine whether it produces a scalar or a list. What matters is context. Always context. And the list context seems to be provided by the parentheses, but is really provided by the list assignment operator. In the examples with the concatenation operator, it is called in scalar context – even with parentheses! Show quoted text
>> Yet it doesn't make much >> sense to me to say that the assignment operator provides scalar context to >> its left operand given that the assignment operator is a scalar or list >> assignment operator depending on the nature of its left operand - i.e. the >> left operand seems to determine the nature of the assignment operator, not >> vice-versa. In the statement '($x,$y)=(5,6);' the left operand is not >> evaluated in scalar context (in which case it would not be a list and we >> would have scalar assignment of 6 to $y with $x and 5 being evaluated in >> void context). I am very confused.
This example is a list assignment because of the parentheses, and therefore the operands are evaluated in list context. Show quoted text
> Context is provided by the left side of an assignment.
By the syntax of the assignment, actually. The context is propagated into the left side operand as well ... Show quoted text
> As r-values, they make lists in > list context or guide precedence in scalar context. This can be > confusing:
No, they only guide precedence either way. use 5.010; use strict; use warnings; say for (1, 0) # scalar context or (2, 3); # list context say for 1, 0 # still scalar context or 2, 3; # still list context __END__ 2 3 2 3 Except for scoping considerations, you could use do{ } blocks instead of parentheses – except where the parentheses are syntactic. Which aside from straightforwardly "different" stuff like function call syntax, prototype declarations, and regexen, would seem to be list assignment and list repetition. (Again, I may be forgetting some other special case.) use 5.010; use strict; use warnings; my $x=1; eval '($x) = 2' or say $@; eval 'do{ $x } = 2' or say $@; say "List repetition: ", join "-", ($x) x 3; say "Scalar repetition: ", join "-", do{$x} x 3; __END__ Can't modify do block in scalar assignment at (eval 2) line 2, at EOF List repetition: 2-2-2 Scalar repetition: 222 Bottom line: There is a whole lot of confusion surrounding lists in Perl. Don't encourage it. Eirik -- Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen a angry penguin charging at them in excess of 100mph. They'd be a lot more careful about what they say if they had. -- Linus Torvalds, announcing Linux v2.0
CC: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Mon, 10 Aug 2009 12:12:16 -0500
To: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 515b
On Mon, Aug 10, 2009 at 11:20 AM, Eirik Berg Hanssen<Eirik- Show quoted text
>> lvalue subroutines are always scalar.
> >  Really now?
and by "always scalar" I mean they are like $x not like @x when getting used as l-values. When not being l-values, lvalue subroutines are perfectly normal. Where "perfectly normal" means "like any other perl subroutine." Sorry for any confusion -- "always" was poor word choice. -- Today in 1680 Taos besieged Santa Fe http://www.amazon.com/exec/obidos/ISBN=1574160648/tipjartransactioA
CC: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>, Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Mon, 10 Aug 2009 22:18:33 +0200
To: David Nicol <davidnicol [...] gmail.com>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 1.2k
David Nicol <davidnicol@gmail.com> writes: Show quoted text
> On Mon, Aug 10, 2009 at 11:20 AM, Eirik Berg Hanssen<Eirik-
>>> lvalue subroutines are always scalar.
>> >>  Really now?
> > and by "always scalar" I mean they are like $x not like @x when > getting used as l-values. When not being l-values, lvalue subroutines > are perfectly normal. Where "perfectly normal" means "like any other > perl subroutine." Sorry for any confusion -- "always" was poor word > choice.
Better, but still not quite right. lvalue subroutines are unlike either of those when used in list assignment: use 5.010; use strict; use warnings; my($x, $y, $f, @f, $g, @h); sub f () :lvalue { $x, $y } say "How many elements do they gobble up?"; ($f, $g, @h) = 0..10; say " A scalar: ", $g // "all"; (f, $g, @h) = 0..10; say " This lvalue subroutine: ", $g // "all"; (@f, $g, @h) = 0..10; say " An array: ", $g // "all"; __END__ How many elements do they gobble up? A scalar: 1 This lvalue subroutine: 2 An array: all Yeah, it's crazy. Crazy powerful. :) But also crazy complex. :-\ See how much simpler it is to note that assignment is list assignment if the left hand operand is an array, a hash, a slice, or enclosed in parentheses? Eirik -- Live and let learn, that's my policy. --Larry Wall
CC: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Mon, 10 Aug 2009 16:43:51 -0500
To: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 965b
On Mon, Aug 10, 2009 at 3:18 PM, Eirik Berg Hanssen<Eirik-Berg.Hanssen@allverden.no> wrote: Show quoted text
> my($x, $y, $f, @f, $g, @h); > sub f () :lvalue { $x, $y } > > (f, $g, @h) = 0..10; > say " This lvalue subroutine: ", $g // "all"; > __END__ >  This lvalue subroutine: 2 > >  Yeah, it's crazy.  Crazy powerful. :)  But also crazy complex. :-\
I would classify that gobbling of two list elements as a bug, as it isn't consistent with anything else. Was it intended, or merely justified? And do $x and $y get loaded with 0 and 1? If so that would mean that the whole "l-value subs are scalar context" thing is false in the face of overwhelming syntax, so f = (5,6); # sets $y to 6, leaves $x alone (f) = (5,6); # sets $x to 5 and $y to 6 would be right. Which is intensely impressive. -- "Galileo never took Tycho's system seriously, as can be seen in his correspondence, regarding it as an inadequate and physically unsatisfactory compromise." -- Wikipedia
CC: David Nicol <davidnicol [...] gmail.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 18:56:28 +1200
To: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
From: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
Download (untitled) / with headers
text/plain 1.4k
Eirik Berg Hanssen wrote: Show quoted text
> See how much simpler it is to note that assignment is list > assignment if the left hand operand is an array, a hash, a slice, or > enclosed in parentheses? > >
I am thinking that should be: an array, a hash, an array or hash slice, or enclosed in parentheses. Because trying to assign to a list slice produces a compile time error on a scalar assignment: my ($x,$y,$z,$h,$i,$j) = (1..6); sub f :lvalue { $x, $y, $z } say f,$h,$i,$j; (f,$h,$i,$j)[1..4] = ('a'..'z'); say f,$h,$i,$j; __END__ Can't modify list slice in scalar assignment at ./test.pl line 10, near ");" Execution of ./test.pl aborted due to compilation errors. Adding parentheses makes it a list assignment, but it still doesn't compile: my ($x,$y,$z,$h,$i,$j) = (1..6); sub f :lvalue { $x, $y, $z } say f,$h,$i,$j; ((f,$h,$i,$j)[1..4]) = ('a'..'z'); say f,$h,$i,$j; __END__ Can't modify list slice in list assignment at ./test.pl line 10, near ");" Execution of ./test.pl aborted due to compilation errors. I guess the compile error is because list slices don't return lvalues. Eirik Berg Hanssen wrote: Show quoted text
> Because parentheses do not make a list, except in a certain > interpretation of the left hand operand of either the assignment > operator or the (in list context) repetition operator. > > Nowhere else. > > (Unless I'm forgetting yet another special case.) > >
None the less, it seems a list slice is a third special case where parentheses make a list. Ian Goodacre
CC: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>, David Nicol <davidnicol [...] gmail.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 09:37:16 +0200
To: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 1.6k
Ian Goodacre <Ian.Goodacre@xtra.co.nz> writes: Show quoted text
> Eirik Berg Hanssen wrote:
>> See how much simpler it is to note that assignment is list >> assignment if the left hand operand is an array, a hash, a slice, or >> enclosed in parentheses? >> >>
> I am thinking that should be: an array, a hash, an array or hash > slice, or enclosed in parentheses. > > Because trying to assign to a list slice produces a compile time error > on a scalar assignment:
Show quoted text
> Adding parentheses makes it a list assignment, but it still doesn't compile:
Show quoted text
> I guess the compile error is because list slices don't return lvalues.
I was not aware of that, but it does rather make sense. :) Show quoted text
> Eirik Berg Hanssen wrote:
>> Because parentheses do not make a list, except in a certain >> interpretation of the left hand operand of either the assignment >> operator or the (in list context) repetition operator. >> >> Nowhere else. >> >> (Unless I'm forgetting yet another special case.) >> >>
> None the less, it seems a list slice is a third special case where > parentheses make a list.
Right again[*]. Good catches both. :) [*]: To the extent that the interpretation to which I was referring is "right". Personally, I'd rather say that the syntax of these three operations provides list context to the expression between those parentheses. But that may just be a knee-jerk reaction against "list anything" that isn't operations or context – the only times we _need_ the concept of lists. ;-) Eirik -- Duck typing: if it walks like a duck, and talks like a duck, then you'd better duck, because the person drawing the gun is probably not an artist. -- Larry Wall
CC: David Nicol <davidnicol [...] gmail.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 22:59:06 +1200
To: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
From: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
Download (untitled) / with headers
text/plain 122b
Thanks for all the comments and examples. I have learned a lot... What do you thing of this revised patch? Ian Goodacre
From e3b7da907b3774fffa3ffeb3b715e914b4612faf Mon Sep 17 00:00:00 2001 From: Ian Goodacre <Ian.Goodacre@xtra.co.nz> Date: Tue, 11 Aug 2009 22:30:15 +1200 Subject: [PATCH] Revised assignment operator docs Elaborated description of list assignment operator, providing a description of left operands that cause an assignment operator to be a list assignment operator, and reorganized section. --- pod/perlop.pod | 53 ++++++++++++++++++++++++++++++++++++----------------- 1 files changed, 36 insertions(+), 17 deletions(-) diff --git a/pod/perlop.pod b/pod/perlop.pod index e677430..bcb5ad4 100644 --- a/pod/perlop.pod +++ b/pod/perlop.pod @@ -729,9 +729,26 @@ X<assignment> X<operator, assignment> X<=> X<**=> X<+=> X<*=> X<&=> X<<< <<= >>> X<&&=> X<-=> X</=> X<|=> X<<< >>= >>> X<||=> X<//=> X<.=> X<%=> X<^=> X<x=> -"=" is the ordinary assignment operator. +"=" is the ordinary assignment operator. There are two forms of this +operator: list assignment and scalar assignment. If the left operand +is an array, a hash, an array or hash slice or enclosed in parentheses, +then the assignment is a list assignment. Otherwise it is a scalar assignment. -Assignment operators work as in C. That is, +There are other assignment operators, as in C. The following are recognized: + + **= += *= &= <<= &&= + -= /= |= >>= ||= + .= %= ^= //= + x= + +These other assignment operators are all scalar assignment operators. +Although they are grouped by family, they all have the precedence +of assignment. + +The scalar assignment operators provide scalar context to both their operands. +The left operand must be an lvalue (meaning you can assign to it). + +The other assignment operators work as in C. That is, $a += 2; @@ -740,18 +757,9 @@ is equivalent to $a = $a + 2; although without duplicating any side effects that dereferencing the lvalue -might trigger, such as from tie(). Other assignment operators work similarly. -The following are recognized: - - **= += *= &= <<= &&= - -= /= |= >>= ||= - .= %= ^= //= - x= +might trigger, such as from tie(). -Although these are grouped by family, they all have the precedence -of assignment. - -Unlike in C, the scalar assignment operator produces a valid lvalue. +Unlike in C, the scalar assignment operators produce a valid lvalue. Modifying an assignment is equivalent to doing the assignment and then modifying the variable that was assigned to. This is useful for modifying a copy of something, like this: @@ -767,10 +775,21 @@ is equivalent to $a += 2; $a *= 3; -Similarly, a list assignment in list context produces the list of -lvalues assigned to, and a list assignment in scalar context returns -the number of elements produced by the expression on the right hand -side of the assignment. +The list assignment operator provides list context to both its operands. + +If the left operand of the list assignment operator is enclosed in parentheses, +each element of the enclosed list must be an lvalue or C<undef>. + +In scalar context, the list assignment operator returns the number of +elements produced by the expression on the right hand side of the +assignment. + +In list context, the list assignment operator returns the list of +lvalues assigned to. + +See L<List value constructors> in L<perldata> for examples of list assignment. + + =head2 Comma Operator X<comma> X<operator, comma> X<,> -- 1.6.1
CC: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>, David Nicol <davidnicol [...] gmail.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 19:16:26 +0200
To: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 764b
Ian Goodacre <Ian.Goodacre@xtra.co.nz> writes: Show quoted text
> Thanks for all the comments and examples. I have learned a lot...
You're welcome. It's nice when one's rants are appreciated. :) Show quoted text
> What do you thing of this revised patch?
It is not my call, but since I've involved myself in this request, I'll continue speaking my mind ... It looks good to me. Certainly a significant improvement on the docs of today. I recommend it. Eirik, with thumbs up -- All the books you read and courses you take in college are just there to help you get familiar with the brushes and the canvas. They'll help keep you from making brown blobs, but you'll never make a masterpiece by the book. -- Robert Simpson, mail-archive.com/sqlite-users%40sqlite.org/msg14592.html
CC: perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 13:52:56 -0500
To: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 849b
I like "list assignment in scalar context" as that is exactly what "the empty list counting trick" is. Show quoted text
> +In scalar context, the list assignment operator returns the number of > +elements produced by the expression on the right hand side of the > +assignment. > + > +In list context, the list assignment operator returns the list of > +lvalues assigned to.
but that is how lists are in scalar context: this behavior is not peculiar to the assignment operator, so these two points might be better combined: As an r-value, the list assignment operator passes its own r-value through. List assignments can be chained, and in a scalar context the result of a list assignment is the number of elements produced by the expression on the right hand side. @XmlThings = m{<thing>(.+)</thing>}gs or do{ warn "no things"; next };
CC: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 21:31:57 +0200
To: David Nicol <davidnicol [...] gmail.com>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 1.5k
David Nicol <davidnicol@gmail.com> writes: Show quoted text
> that is how lists are in scalar context
I feel another rant coming up ... one of the old ones: Lists are never in scalar context. List assignment may be, list slices may be, but lists may not. (List repetitions may not be in scalar context either, surpisingly enough. It is an operation that only exists in list context.) Show quoted text
> As an r-value, the list assignment operator passes its own > r-value through.
What is "its own r-value"? If you mean to say the "elements produced by the expression on the right hand side of the assignment", it is incorrect. (And if you meant something else, I found it less clear than what the patch had.) use 5.010; use strict; use warnings; my @x = my ($x, undef, $y) = 1..10; say $_||'undef' for @x; __END__ 1 2 3 3 elements, not 10. Specifically, the three elements assigned to. Aside: And none of them undef either. In fact, this is one ... rather _special_ ... corner case: use 5.010; use strict; use warnings; for my $u (undef) { my @x = ($u) = 1..10; say $_||'undef' for @x, $u; } __END__ 1 undef The assignment to ($u) evaluates to a list of one element, the value of which differs from the value of $u, which remains the same both before and after the assignment. Ah, the magic of undef. :) Eirik -- -------- Rule of Feline Frustration: -------* I bet you never noticed that When your cat has fallen asleep on your lap | "homeowner" has the word and looks utterly content and adorable, you | "meow" in the middle of it. will suddenly have to go to the bathroom. *------------- P. McGraw ----
CC: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 15:40:44 -0500
To: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 1.9k
On Tue, Aug 11, 2009 at 2:31 PM, Eirik Berg Hanssen<Eirik- Show quoted text
>>      As an r-value, the list assignment operator passes its own >> r-value through.
> >  What is "its own r-value"?  If you mean to say the "elements > produced by the expression on the right hand side of the assignment", > it is incorrect. > >  (And if you meant something else, I found it less clear than what > the patch had.)
Yes, that's what I meant. Thanks for straightening out my misconception. Show quoted text
> > use 5.010; > use strict; > use warnings; > my @x = my ($x, undef, $y) = 1..10; > say $_||'undef' for @x; > __END__ > 1 > 2 > 3 > >  3 elements, not 10.  Specifically, the three elements assigned to.
wow. /tmp: $ perl -le '@a=qw/24 57 32 hike!/; $count = () = @a; print $count' 4 /tmp: $ perl -le '@a=qw/24 57 32 hike!/; @copy = () = @a; print @copy' /tmp: $ So list assignment in scalar context returns the count of the RHS, but list assignment in list context returns the LHS. Show quoted text
> >  Aside: > >  And none of them undef either.  In fact, this is one ... rather > _special_ ... corner case: > > use 5.010; > use strict; > use warnings; > for my $u (undef) { >  my @x = ($u) = 1..10; >  say $_||'undef' for @x, $u; > } > __END__ > 1 > undef > >  The assignment to ($u) evaluates to a list of one element, the value > of which differs from the value of $u, which remains the same both > before and after the assignment.  Ah, the magic of undef. :)
Is that not a bug, that an assignment to a constant ($u is an alias to undef) did not cause an exception? It looks like undef is special that way. /tmp: $ perl -le ' $count = undef = 3; print $count' Modification of a read-only value attempted at -e line 1. /tmp: $ perl -le ' ($count) = (undef) = (3); print $count' 3 /tmp: $ perl -le ' ($count) = (22) = (3); print $count' Can't modify constant item in list assignment at -e line 1, near ");" Execution of -e aborted due to compilation errors. /tmp: $
CC: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>, Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Tue, 11 Aug 2009 18:02:21 -0500
To: David Nicol <davidnicol [...] gmail.com>
From: Graham Barr <gbarr [...] pobox.com>
Download (untitled) / with headers
text/plain 962b
On Aug 11, 2009, at 3:40 PM, David Nicol wrote: Show quoted text
> > > /tmp: $ perl -le '@a=qw/24 57 32 hike!/; $count = () = @a; print > $count' > 4 > /tmp: $ perl -le '@a=qw/24 57 32 hike!/; @copy = () = @a; print @copy' > > /tmp: $ > > So list assignment in scalar context returns the count of the RHS, but > list assignment in list context returns the LHS.
unless the element in the LHS is undef, in which case it returns the RHS value for that element, as can be seen in $ perl -le '@a=qw/24 57 32 hike!/; @copy = ($x,undef,$y) = @a; $,=","; print @copy' 24,57,32 I was about to say that a list assignment in a list context returns the first N elements of the RHS, where N is the number of elements on the LHS, but this is not true when tied variables are involved {package Bar; sub TIESCALAR { return bless {} } sub STORE { return 99 } sub FETCH { return 88 } } tie $x, 'Bar'; $,=","; @copy = ($x,$y) = (1,2); print @copy; will output 88,2 Graham.
CC: David Nicol <davidnicol [...] gmail.com>, Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>, Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>, perlbug-followup [...] perl.org
Subject: Re: [perl #68312] perlop / list assignment documentation
Date: Wed, 12 Aug 2009 09:45:35 +0200
To: Graham Barr <gbarr [...] pobox.com>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Download (untitled) / with headers
text/plain 1.6k
Graham Barr <gbarr@pobox.com> writes: Show quoted text
> On Aug 11, 2009, at 3:40 PM, David Nicol wrote:
Show quoted text
>> So list assignment in scalar context returns the count of the RHS, but >> list assignment in list context returns the LHS.
> > unless the element in the LHS is undef, in which case it returns the > RHS value for that element, as can be seen in > > $ perl -le '@a=qw/24 57 32 hike!/; @copy = ($x,undef,$y) = @a; $,=","; > print @copy' > 24,57,32
The RHS value, perhaps, but not the RHS element itself. Just like your elegant tied() demonstration, list assignment in lvalue list context reveals that what is returned is a copy of the RHS element – even in the case of a constant undef on the LHS: use 5.010; use strict; use warnings; my $y = 2; for my $u (undef) { my ($x1, $x2); for my $x (($x1, undef, $u, $x2)=($y, $y, $y, $y)) { $x**=2; $y++; say "x: $x; y: $y, u: " . ($u//'undef'); } } __END__ x: 4; y: 3, u: undef x: 4; y: 4, u: undef x: 4; y: 5, u: undef x: 4; y: 6, u: undef Compare: use 5.010; use strict; use warnings; my $y = 2; for my $x (($y, $y, $y, $y)) { $x**=2; $y++; say "x: $x; y: $y"; } __END__ x: 5; y: 5 x: 26; y: 26 x: 677; y: 677 x: 458330; y: 458330 Without spending too much text on corner cases nor misleading the reader too much, "the list of lvalues assigned to", as in the docs both before and after the proposed patch, is about as informative as it gets on this issue. Or so I suspect. Eirik -- The basic facts are that the rate of decrease of the population growth rate has been falling for decades, at an ever increasing rate. --jsnead@netcom.com (John R. Snead)
Subject: Re: [perl #68312] perlbug AutoReply: perlop / list assignment documentation
Date: Mon, 31 Aug 2009 03:45:13 +1200
To: perlbug-followup [...] perl.org
From: Ian Goodacre <Ian.Goodacre [...] xtra.co.nz>
Download (untitled) / with headers
text/plain 3.5k
Below is a revision of the patch to perlop.pod which incorporates some detail of the handling of undef on LHS of a list assignment, From http://www.perlmonks.org/?node_id=791113. diff --git a/pod/perlop.pod b/pod/perlop.pod index 1df9fcb..7120a8c 100644 --- a/pod/perlop.pod +++ b/pod/perlop.pod @@ -729,9 +729,26 @@ X<assignment> X<operator, assignment> X<=> X<**=> X<+=> X<* X<<< <<= >>> X<&&=> X<-=> X</=> X<|=> X<<< >>= >>> X<||=> X<//=> X<.=> X<%=> X<^=> X<x=> -"=" is the ordinary assignment operator. +"=" is the ordinary assignment operator. There are two forms of this +operator: list assignment and scalar assignment. If the left operand +is an array, a hash, an array or hash slice or enclosed in parentheses, +then the assignment is a list assignment. Otherwise it is a scalar assignment. -Assignment operators work as in C. That is, +There are other assignment operators, as in C. The following are recognized: + + **= += *= &= <<= &&= + -= /= |= >>= ||= + .= %= ^= //= + x= + +These other assignment operators are all scalar assignment operators. +Although they are grouped by family, they all have the precedence +of assignment. + +The scalar assignment operators provide scalar context to both their operands. +The left operand must be an lvalue (meaning you can assign to it). + +The other assignment operators work as in C. That is, $a += 2; @@ -740,18 +757,9 @@ is equivalent to $a = $a + 2; although without duplicating any side effects that dereferencing the lvalue -might trigger, such as from tie(). Other assignment operators work similarly. -The following are recognized: - - **= += *= &= <<= &&= - -= /= |= >>= ||= - .= %= ^= //= - x= - -Although these are grouped by family, they all have the precedence -of assignment. +might trigger, such as from tie(). -Unlike in C, the scalar assignment operator produces a valid lvalue. +Unlike in C, the scalar assignment operators produce a valid lvalue. Modifying an assignment is equivalent to doing the assignment and then modifying the variable that was assigned to. This is useful for modifying a copy of something, like this: @@ -767,10 +775,29 @@ is equivalent to $a += 2; $a *= 3; -Similarly, a list assignment in list context produces the list of -lvalues assigned to, and a list assignment in scalar context returns -the number of elements produced by the expression on the right hand -side of the assignment. +The list assignment operator provides list context to both of its operands. + +If the left operand of the list assignment operator is enclosed in parentheses, +each element of the enclosed list must be an lvalue or C<undef>. + +In scalar context, the list assignment operator returns the number of +elements produced by the expression on the right hand side of the +assignment. + +In list context, the list assignment operator returns the list of +lvalues assigned to. Where the value in the LHS list is C<undef> +the corresponding value from the RHS is returned or, if there is +any value in common between the LHS and RHS, a copy of the corresponding +value from the RHS is returned. The difference is significant if +the returned values are modified (e.g. in a for loop or map). + + map {$_++} (($x, undef) = ($y, $z)) # increments $x and $z + map {$_++} (($x, undef) = ($y, $z, $x)) # increments $x and a copy of $z + + +See L<List value constructors> in L<perldata> for examples of list assignment. + + =head2 Comma Operator X<comma> X<operator, comma> X<,>
RT-Send-CC: perl5-porters [...] perl.org
There was a lot of back-and-forth and revision of patches in this RT before discussion petered out about 2-1/2 years ago. Could people evaluate the last patch submitted, below? Thank you very much. Jim Keenan On Sun Aug 30 08:46:10 2009, iang wrote: Show quoted text
> Below is a revision of the patch to perlop.pod which incorporates > some detail of the handling of undef on LHS of a list assignment, > From http://www.perlmonks.org/?node_id=791113. > > diff --git a/pod/perlop.pod b/pod/perlop.pod > index 1df9fcb..7120a8c 100644 > --- a/pod/perlop.pod > +++ b/pod/perlop.pod > @@ -729,9 +729,26 @@ X<assignment> X<operator, assignment> X<=> X<**=> > X<+=> X<* > X<<< <<= >>> X<&&=> X<-=> X</=> X<|=> X<<< >>= >>> X<||=> X<//=> X<.=> > X<%=> X<^=> X<x=> > > -"=" is the ordinary assignment operator. > +"=" is the ordinary assignment operator. There are two forms of this > +operator: list assignment and scalar assignment. If the left operand > +is an array, a hash, an array or hash slice or enclosed in parentheses, > +then the assignment is a list assignment. Otherwise it is a scalar > assignment. > > -Assignment operators work as in C. That is, > +There are other assignment operators, as in C. The following are > recognized: > + > + **= += *= &= <<= &&= > + -= /= |= >>= ||= > + .= %= ^= //= > + x= > + > +These other assignment operators are all scalar assignment operators. > +Although they are grouped by family, they all have the precedence > +of assignment. > + > +The scalar assignment operators provide scalar context to both their > operands. > +The left operand must be an lvalue (meaning you can assign to it). > + > +The other assignment operators work as in C. That is, > > $a += 2; > > @@ -740,18 +757,9 @@ is equivalent to > $a = $a + 2; > > although without duplicating any side effects that dereferencing the
lvalue Show quoted text
> -might trigger, such as from tie(). Other assignment operators work > similarly. > -The following are recognized: > - > - **= += *= &= <<= &&= > - -= /= |= >>= ||= > - .= %= ^= //= > - x= > - > -Although these are grouped by family, they all have the precedence > -of assignment. > +might trigger, such as from tie(). > > -Unlike in C, the scalar assignment operator produces a valid lvalue. > +Unlike in C, the scalar assignment operators produce a valid lvalue. > Modifying an assignment is equivalent to doing the assignment and > then modifying the variable that was assigned to. This is useful > for modifying a copy of something, like this: > @@ -767,10 +775,29 @@ is equivalent to > $a += 2; > $a *= 3; > > -Similarly, a list assignment in list context produces the list of > -lvalues assigned to, and a list assignment in scalar context returns > -the number of elements produced by the expression on the right hand > -side of the assignment. > +The list assignment operator provides list context to both of its
operands. Show quoted text
> + > +If the left operand of the list assignment operator is enclosed in > parentheses, > +each element of the enclosed list must be an lvalue or C<undef>. > + > +In scalar context, the list assignment operator returns the number of > +elements produced by the expression on the right hand side of the > +assignment. > + > +In list context, the list assignment operator returns the list of > +lvalues assigned to. Where the value in the LHS list is C<undef> > +the corresponding value from the RHS is returned or, if there is > +any value in common between the LHS and RHS, a copy of the corresponding > +value from the RHS is returned. The difference is significant if > +the returned values are modified (e.g. in a for loop or map). > + > + map {$_++} (($x, undef) = ($y, $z)) # increments $x and $z > + map {$_++} (($x, undef) = ($y, $z, $x)) # increments $x and a copy > of $z > + > + > +See L<List value constructors> in L<perldata> for examples of list > assignment. > + > + > > =head2 Comma Operator > X<comma> X<operator, comma> X<,> >
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 4.4k
On Wed Mar 28 18:40:43 2012, jkeenan wrote: Show quoted text
> There was a lot of back-and-forth and revision of patches in this RT > before discussion petered out about 2-1/2 years ago. > > Could people evaluate the last patch submitted, below?
I thought the consensus was that that was far too much detail, and that the exact details may be subject to change. Show quoted text
> > Thank you very much. > Jim Keenan > > On Sun Aug 30 08:46:10 2009, iang wrote:
> > Below is a revision of the patch to perlop.pod which incorporates > > some detail of the handling of undef on LHS of a list assignment, > > From http://www.perlmonks.org/?node_id=791113. > > > > diff --git a/pod/perlop.pod b/pod/perlop.pod > > index 1df9fcb..7120a8c 100644 > > --- a/pod/perlop.pod > > +++ b/pod/perlop.pod > > @@ -729,9 +729,26 @@ X<assignment> X<operator, assignment> X<=> X<**=> > > X<+=> X<* > > X<<< <<= >>> X<&&=> X<-=> X</=> X<|=> X<<< >>= >>> X<||=> X<//=> X<.=> > > X<%=> X<^=> X<x=> > > > > -"=" is the ordinary assignment operator. > > +"=" is the ordinary assignment operator. There are two forms of this > > +operator: list assignment and scalar assignment. If the left operand > > +is an array, a hash, an array or hash slice or enclosed in parentheses, > > +then the assignment is a list assignment. Otherwise it is a scalar > > assignment. > > > > -Assignment operators work as in C. That is, > > +There are other assignment operators, as in C. The following are > > recognized: > > + > > + **= += *= &= <<= &&= > > + -= /= |= >>= ||= > > + .= %= ^= //= > > + x= > > + > > +These other assignment operators are all scalar assignment operators. > > +Although they are grouped by family, they all have the precedence > > +of assignment. > > + > > +The scalar assignment operators provide scalar context to both their > > operands. > > +The left operand must be an lvalue (meaning you can assign to it). > > + > > +The other assignment operators work as in C. That is, > > > > $a += 2; > > > > @@ -740,18 +757,9 @@ is equivalent to > > $a = $a + 2; > > > > although without duplicating any side effects that dereferencing the
> lvalue
> > -might trigger, such as from tie(). Other assignment operators work > > similarly. > > -The following are recognized: > > - > > - **= += *= &= <<= &&= > > - -= /= |= >>= ||= > > - .= %= ^= //= > > - x= > > - > > -Although these are grouped by family, they all have the precedence > > -of assignment. > > +might trigger, such as from tie(). > > > > -Unlike in C, the scalar assignment operator produces a valid lvalue. > > +Unlike in C, the scalar assignment operators produce a valid lvalue. > > Modifying an assignment is equivalent to doing the assignment and > > then modifying the variable that was assigned to. This is useful > > for modifying a copy of something, like this: > > @@ -767,10 +775,29 @@ is equivalent to > > $a += 2; > > $a *= 3; > > > > -Similarly, a list assignment in list context produces the list of > > -lvalues assigned to, and a list assignment in scalar context returns > > -the number of elements produced by the expression on the right hand > > -side of the assignment. > > +The list assignment operator provides list context to both of its
> operands.
> > + > > +If the left operand of the list assignment operator is enclosed in > > parentheses, > > +each element of the enclosed list must be an lvalue or C<undef>. > > + > > +In scalar context, the list assignment operator returns the number of > > +elements produced by the expression on the right hand side of the > > +assignment. > > + > > +In list context, the list assignment operator returns the list of > > +lvalues assigned to. Where the value in the LHS list is C<undef> > > +the corresponding value from the RHS is returned or, if there is > > +any value in common between the LHS and RHS, a copy of the
corresponding Show quoted text
> > +value from the RHS is returned. The difference is significant if > > +the returned values are modified (e.g. in a for loop or map). > > + > > + map {$_++} (($x, undef) = ($y, $z)) # increments $x and $z > > + map {$_++} (($x, undef) = ($y, $z, $x)) # increments $x and a copy > > of $z > > + > > + > > +See L<List value constructors> in L<perldata> for examples of list > > assignment. > > + > > + > > > > =head2 Comma Operator > > X<comma> X<operator, comma> X<,> > >
> >
-- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 521b
On Wed Mar 28 22:58:33 2012, sprout wrote: Show quoted text
> On Wed Mar 28 18:40:43 2012, jkeenan wrote:
> > There was a lot of back-and-forth and revision of patches in this RT > > before discussion petered out about 2-1/2 years ago. > > > > Could people evaluate the last patch submitted, below?
> > I thought the consensus was that that was far too much detail, and that > the exact details may be subject to change. >
> >
Should we take that as a recommendation to reject and close the ticket? Thank you very much. Jim Keenan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 718b
On Thu Apr 05 19:09:01 2012, jkeenan wrote: Show quoted text
> On Wed Mar 28 22:58:33 2012, sprout wrote:
> > On Wed Mar 28 18:40:43 2012, jkeenan wrote:
> > > There was a lot of back-and-forth and revision of patches in this RT > > > before discussion petered out about 2-1/2 years ago. > > > > > > Could people evaluate the last patch submitted, below?
> > > > I thought the consensus was that that was far too much detail, and that > > the exact details may be subject to change. > >
> > >
> > Should we take that as a recommendation to reject and close the ticket?
I think we should close it, if simply because it makes it easier to fix bugs if things are not explained in such excruciating detail. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 332b
On Fri Apr 06 06:22:20 2012, sprout wrote: Show quoted text
> On Thu Apr 05 19:09:01 2012, jkeenan wrote:
> > > > Should we take that as a recommendation to reject and close the ticket?
> > I think we should close it, if simply because it makes it easier to fix > bugs if things are not explained in such excruciating detail. >
Closing ticket.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org