Replying to myself to clear a few things up...
In a message dated Mon, 23 Sep 2002, Trey Harris writes:
> 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.
This is, I imagine, where Simon saw magic. I suspect that, for all X, it
would be magic if true (pretty neat magic, though!). I started with a
literal 7 instead of an abstract X, and then went back and changed it. I
shouldn't have done so.
> 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
That last line should read
($a, $b) = (1, 2); # $a = 1, $b = 2
> 7. Miscellanea.
> What
>
> for (1,("a","b","c"),3 { ... }
There's a missing paren here. Should read
for (1,("a","b","c"),3) { ... }
> 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.
I take this back. Apparently splat was always "shallowly flattening".
Something bothers me about that, but it seems better than the alternative.
Can anyone think of a cause where you need a "deeply flattening" operator?
Seems to be that there's a common one that I can't quite put my finger
on...
> 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);
I think this might be the answer. One-tuples can't be created with a
simple (N). If you want a one-tuple, you use [], and if you want to
coerce a list context onto something that might return a single element,
you use @(). That's analogous to how it works in Perl 5, and
list-vs.-array behavior is one thing that I'd argue is *not* broken in
Perl 5. Being able to use arbitrary lists as lvalues, being able to index
lists as if they were arrays, being able to construct lists easily out of
disparate scalar and list constituents, etc., are one of the major things
that make Perl a joy to use.
Trey
