I think this discussion has gotten out of hand, and I hope that Larry,
Damian or Allison will grace us with a resolution soon. :-)
May I suggest that we start with some DWIMmy examples and try to arrive at
a mechanism that will make them all DWIM? Here are my opinions, feel free
to shoot them down if you disagree:
1. Subroutines calls.
Given the prototype
sub func(*@ary);
Then
func(X, Y, ..., Z)
should be equivalent to
(func X, Y, ..., Z)
Given the prototype
sub func($scalar);
with no other definitions of func(), then
func(X, Y, ..., Z)
should raise an exception, while
(func X, Y, ..., Z)
should be equivalent to
((func X), Y, ..., Z)
and create a list.
2. Scalar assignment.
my $a; # 1.
$a = X;
my $a; # 2.
$a = X;
my $a; # 3.
($a) = X;
my($a) = X; # 4.
my($a) = (X); # 5.
These should all do the same thing, regardless of X.
3. Precedence.
Adding an additional set of parentheses around an expression already
surrounded by parentheses should never cause that expression to change
meaning. That is to say
(N) === ((N))
(=== meaning "is equivalent to") for all expressions N. Precedence is one
of the hardest things for many programmers, especially unsophisticated
ones, to grasp. At least in Perl 5, the programmer can always overdo it
with parentheses if she is unsure. Requiring that the programmer get
precedence *exactly* right, because one too many parens will result in
coercion of the expression into a list, and thus usually coerced
numerically back to the value 1, is completely unacceptable.
4. Numeric value.
The progression spoken about at great length previously:
+() # == 0
+(0) # == WHAT? 0? 1?
+(0,1) # == 2
+(0,1,2) # == 3
+(0,1,2,3) # == 4
+(0,...,n) # == n + 1
is largely irrelevant to the ways people use Perl. It may look odd framed
so clearly as a progression, but programmers do not ordinarily create
literal lists simply in order to take the length of them. This is a cute
programming puzzle that sadistic technical interviewers will foist on
frightened young job candidates in a few years, but I think it has little
bearing on language design.
Thus, item 3 on precedence above usually applies even in the N === (N)
case (though it may sometimes fail to apply because of parsing rules).
And the answer to WHAT above is 0, aesthetics of the progression be
damned.
5. Assignment to arrays and lists.
The following should be vaild:
($a, $b) = ($b, $a); # swaps $a and $b
($a, $b) = (1, 2); # $a == 1, $b == 2
($a, $b, $c) ^*= 2; # doubles each of $a, $b and $c
@a = (1, 2, 3); # Same as Perl 5
$a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
6. List slicing.
These expressions should both be valid and have the value 2:
(1,2,3,4)[1]
[1,2,3,4][1]
7. Miscellanea.
for 1,2,3,4 { ... }
should be equivalent to
for (1,2,3,4) { ... }
and
for 1,["a","b","c"],3 { print "x"; }
should print "xxx".
What
for (1,("a","b","c"),3 { ... }
and
for 1,("a","b","c"),3 { ... }
do is left for Larry and/or Damian to answer, but whatever they do, the
two lines should be equivalent.
Now that I've ventured away from DWIMs and more into WIHDTEMs (What In
Hell Does This Expression Mean), is the above equivalent to
for 1,qw(a b c), 3 { ... }
as well?
A final unresolved question. I take it that the splat operator is a
deeply flattening operator. For instance,
*[1,[2,[3,4,5]],6]
will be converted into
[1,2,3,4,5,6]
It seems that, if the new order does allow the creation of
multi-dimensional things using simply (), that we also need a "shallowly
flattening operator". That is, it would convert the above list into
[1,2,[3,4,5],6]
Otherwise, the flattening required by the new syntax can go wild and cause
unwanted flattening in data structures being passed around.
--
In conclusion, my reading of what Larry has said is compatible with the
above--ASSUMING that
$a = (7);
causes $a to have the value 7, not the value [7]. If it has the value
[7], as seems to be the result of the reduction that many here have been
doing, then we have a very large problem with precedence, because as I
said in item 3, we can't rely on people getting the paren count exactly
right. Several other DWIMs above also fall apart.
So, if you want to create a one-item list, you're left with
$a = [7];
or possibly
$a = @(7);
It seems to me that the vagaries of the one-element list and the coarse
level of control provided by the flattening operator has gotten us into
this level of confusion. I hope Larry, Damian, Allison or somebody "in
charge" :-) can help us out of it.
Trey
