>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Dan Sugalski writes:
LW> : And do we want to consider making this (and its ilk) Do The Right Thing?
LW> :
LW> : (@foo, @bar) = (@bar, @foo);
LW> We certainly want to consider it, though perhaps not in -internals.
LW> You can talk about passing @bar and @foo around as lazy lists, and
LW> maybe even do lazy list-flattening, but I don't see how that works yet,
LW> even in the absence of overlap. The basic issue here may come
LW> down to whether the LHS of an assignment can supply a prototype for the
LW> entire assignment that forces everything to be treated as objects
LW> rather than lists.
LW> That is, right now, we can only have a scalar assignment prototype of ($),
LW> and a list assignment prototype of (@). We need a prototype (not just
LW> for assignment) that says "all the rest of these arguments are objects",
LW> so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@).
LW> Or (\@*) for short.
Isn't that what Damian's named (whatever, formerly known as prototypes) does?
@_ in the absence of a named argument list would continue to act _as if_
the argument list were flattened. With a named argument list, it would
make the actual refs on the stack visible.
The question that I think Dan proposed is how much breakage would
infering (@foo, @bar) = (@bar, @foo) to mean treat RHS as objects, cause.
Wouldn't having and @ anywhere but the last position in the list would
be a useful indicator. I can see someone (Probably Randal or Tom)
wanting to initialize a list that way. But for the rest of us, it
isn't that useful.
LW> P.S. I think we *could* let @foo and %bar return an object ref in scalar
LW> context, as long as the object returned overloads itself to behave as
LW> arrays and hashes currently do in scalar context.
Isn't this an internals issue?
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
