At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: The core will already know.
>
>Especially if we add return types.
Sure. Can't hurt to add code to optimize 'old-style' perl 5 code either,
though.
>: Whether this justifies exposing the information's for someone else to
>: judge, but the core will know what context something is in. This is for
>: optimization reasons. While it's straightforward enough to know that this
>: is a hash copy:
>:
>: %foo = %bar;
>:
>: which can be optimized, it's less easy to optimize this:
>:
>: sub foo {
>: my %hash;
>: %hash = (1..10000);
>: return %hash;
>: }
>:
>: %bar = foo();
>:
>: without return knowing its argument's in list(hash) context. If we know
>: that, though, the function return can be quicker than it would be if we
>: flatten and reconstitute the hash.
>
>I expect that we'll get more compile-time benefit from
>
> my HASH sub foo {
> ...
> }
>
> %bar = foo();
Sure. It's still a win without the declaration, though.
And do we want to consider making this (and its ilk) Do The Right Thing?
(@foo, @bar) = (@bar, @foo);
The Right Thing, in this case, being a swap of @foo and @bar? I'm thinking
about what'd happen if lists were turned into first-class data structures
with lazy (and too darned clever) evaluation, though I suppose that lists
laziness is orthogonal to this. (Lazy lists would allow for other
optimizations, though)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
