At 05:38 PM 7/18/2001 -0400, Chris Devers wrote:
>On Wed, 18 Jul 2001, Dan Sugalski wrote:
>
> > It also means that perl may be able to do:
> >
> > (@foo, @bar) = baz();
> >
> > and really have data go into both @foo and @bar--since we don't
> flatten, it
> > means array and hash elements don't lose their grouping on assignment or
> > subroutine returns, so we can figure out how to do this right. (Whether we
> > *will* or not is a separate issue, and that's Larry's problem. I'm just
> > going to make sure the mechanism is there if he chooses to expose it)
>
>Very interesting. So, if the mechanism is going to be there anyway, will
>there be a way to poke at it if Larry decides not to expose it?
At the internals level, yes. You'll have to deal with this if you chose to
write an alternate list implementation. (Not that too many people will want
to do that... :) Or if you write another language, or a language variant,
that uses Parrot as its runtime.
>It's tantalizing to know what interesting things will be going on under
>the hood, and yet we might not be able to work with some of them...
Just because it's there doesn't necessarily mean that it ought to be
exposed in perl. (Heck, lists will be lazy in some circumstances if there
are function calls in them, but that doesn't mean we're necessarily
exposing that either) There are pretty good aesthetic and artistic
integrity arguments to be mustered to not unconditionally expose this sort
of thing.
I do know the:
(@foo, @bar) = (@bar, @foo);
swapping argument, and ones like it, have been raised in the perl 6 design
cycle, so it may well be there in some form or another. And you can always
write a parser extension... :-)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
