[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl6-language
Subject:    Re: Multi-d array transforms (was Re: Array rotate)
From:       "John M. Dlugosz" <2nb81lz02 () sneakemail ! com>
Date:       2009-06-14 0:01:01
Message-ID: 7175-34936 () sneakemail ! com
[Download RAW message or body]

Larry Wall larry-at-wall.org |Perl 6| wrote:
> On Sat, Jun 13, 2009 at 02:49:10PM -0500, John M. Dlugosz wrote:
>   
>> Wow.  The overarching logic for list assignment would have to compare  
>> the containers and the arguments in the capture before doing the list  
>> assignment to each container, in order to avoid cloning all the  
>> containers on the right first in the general case.  It can't just copy  
>> values out because they may contain iterators or be lazy or be infinite.
>>     
>
> Well, that's not really a problem, as long as the same semantics
> are preserved.  All you need to do is cut loose the contents of the
> container completely to the mercy of GC, build a new one with the
> appropriate structure, then copy values in from the assignment's RHS.
> The only reason Perl 5 couldn't do it this way is that the idiot who
> wrote it prematurely optimized values on the stack so that they didn't
> need to be reference counted. :)
>
> Larry
>
>   
I agree, if "the contents" include the iterators and code blocks and 
whatnot that make up the concrete types of the things on the right.  But 
if it's not a built-in standard type, it might require a call to the 
general shallow-copy clone of the object.

   my @A is CustomContainer;
   my @B[7];  # fixed size
   ...
   @B,@A,@C = @A,@B;

The compiler doesn't know how to juggle the internals of @A because it 
is not a standard type.  This needs to become:

    my @temp1 = @A.clone;
    my @temp2 = @B.clone;
    @B,@A,@C = @temp1,@temp2;

and assume that the compiler might optimize the case with @B through 
innate knowledge, and possibly inline and optimize over the calls for @A.



Premature optimization is the root of all evil.

But... design the semantics so there is some hope of optimization.  That 
might entail designing in some features of Positional that will be used 
by this construct, as more efficient than just calling .clone().

OTOH, machines are a million times faster than what Perl 4 originally 
ran on.
[prev in list] [next in list] [prev in thread] [next in thread]