Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perlop / list assignment documentation #9820

Closed
p5pRT opened this issue Aug 7, 2009 · 29 comments
Closed

perlop / list assignment documentation #9820

p5pRT opened this issue Aug 7, 2009 · 29 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 7, 2009

Migrated from rt.perl.org#68312 (status was 'rejected')

Searchable as RT68312$

@p5pRT
Copy link
Author

p5pRT commented Aug 7, 2009

From @ig3

Created by ian@alula.local

Here is a patch to perlop.pod which, I think, clarifies the
description of the assignment operator a little.

Perl Info

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


@p5pRT
Copy link
Author

p5pRT commented Aug 7, 2009

From @ig3

0001-Clarified-description-of-the-assignment-operator.patch
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

@p5pRT
Copy link
Author

p5pRT commented Aug 8, 2009

From Eirik-Berg.Hanssen@allverden.no

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

@p5pRT
Copy link
Author

p5pRT commented Aug 8, 2009

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

@p5pRT
Copy link
Author

p5pRT commented Aug 8, 2009

From Eirik-Berg.Hanssen@allverden.no

Eirik Berg Hanssen <Eirik-Berg.Hanssen@​allverden.no> writes​:

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.

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2009

From @ig3

Eirik Berg Hanssen via RT wrote​:

"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

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2009

From @davidnicol

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

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.

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.

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.

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.

Regards,
Ian Goodacre

--
Today in 1680 Taos besieged Santa Fe
http​://www.amazon.com/exec/obidos/ISBN=1574160648/tipjartransactioA

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2009

From Eirik-Berg.Hanssen@allverden.no

David Nicol <davidnicol@​gmail.com> writes​:

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

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!

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.

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

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

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2009

From @davidnicol

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.

--
Today in 1680 Taos besieged Santa Fe
http​://www.amazon.com/exec/obidos/ISBN=1574160648/tipjartransactioA

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2009

From Eirik-Berg.Hanssen@allverden.no

David Nicol <davidnicol@​gmail.com> writes​:

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

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2009

From @davidnicol

On Mon, Aug 10, 2009 at 3​:18 PM, Eirik Berg
Hanssen<Eirik-Berg.Hanssen@​allverden.no> wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From @ig3

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​:

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​:

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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From Eirik-Berg.Hanssen@allverden.no

Ian Goodacre <Ian.Goodacre@​xtra.co.nz> writes​:

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​:

Adding parentheses makes it a list assignment, but it still doesn't compile​:

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. :)

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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From @ig3

Thanks for all the comments and examples. I have learned a lot...

What do you thing of this revised patch?

Ian Goodacre

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From @ig3

0001-Revised-assignment-operator-docs.patch
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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From Eirik-Berg.Hanssen@allverden.no

Ian Goodacre <Ian.Goodacre@​xtra.co.nz> writes​:

Thanks for all the comments and examples. I have learned a lot...

  You're welcome. It's nice when one's rants are appreciated. :)

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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From @davidnicol

I like "list assignment in scalar context" as that is exactly what
"the empty list counting trick" is.

+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
  };

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From Eirik-Berg.Hanssen@allverden.no

David Nicol <davidnicol@​gmail.com> writes​:

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

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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From @davidnicol

On Tue, Aug 11, 2009 at 2​:31 PM, Eirik Berg Hanssen<Eirik-

     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.

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.

 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​: $

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2009

From @gbarr

On Aug 11, 2009, at 3​:40 PM, David Nicol wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Aug 12, 2009

From Eirik-Berg.Hanssen@allverden.no

Graham Barr <gbarr@​pobox.com> writes​:

On Aug 11, 2009, at 3​:40 PM, David Nicol wrote​:

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)

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2009

From @ig3

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.

Inline Patch
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\

-"=" 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<,>

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2012

From @jkeenan

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​:

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<,>

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2012

From @cpansprout

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.

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
+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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2012

From @jkeenan

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?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2012

From @cpansprout

On Thu Apr 05 19​:09​:01 2012, jkeenan wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2012

From [Unknown Contact. See original ticket]

On Thu Apr 05 19​:09​:01 2012, jkeenan wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2012

From @jkeenan

On Fri Apr 06 06​:22​:20 2012, sprout wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2012

@jkeenan - Status changed from 'open' to 'rejected'

@p5pRT p5pRT closed this as completed Apr 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant