Dan Sugalski writes:
: And do we want to consider making this (and its ilk) Do The Right Thing?
:
: (@foo, @bar) = (@bar, @foo);
We certainly want to consider it, though perhaps not in -internals.
You can talk about passing @bar and @foo around as lazy lists, and
maybe even do lazy list-flattening, but I don't see how that works yet,
even in the absence of overlap. The basic issue here may come
down to whether the LHS of an assignment can supply a prototype for the
entire assignment that forces everything to be treated as objects
rather than lists.
That is, right now, we can only have a scalar assignment prototype of ($),
and a list assignment prototype of (@). We need a prototype (not just
for assignment) that says "all the rest of these arguments are objects",
so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@).
Or (\@*) for short.
Though if we let @foo and %bar automatically return refs in a scalar context
rather than booleans, we might write that as (;$$$$$$$$$$$$$$$$$). ($*) for
short. (Presuming * to be available if typeglobs go away.)
However we force non-flattening object lists in prototypes, there's
still the question of how you specify the use of an object list
prototype on assignment. Hmm.
(@foo, @bar) \= (@bar, @foo);
Dunno if I like that or not.
Larry
P.S. I think we *could* let @foo and %bar return an object ref in scalar
context, as long as the object returned overloads itself to behave as
arrays and hashes currently do in scalar context.
Larry
