Christian Soeller wrote:
> Chaim Frenkel wrote:
>
> >
> > The current thinking in -internals is that list flattening will be
delayed
> > to as late as possible.
> >
> > One possiblity would be that only @_ would do any flattening. It would
> > walk each argument with an appropriate iterator to return the flattened
> > list.
> >
> > A parameter list would then have access to the actual items on the list.
>
> That sounds good. However, doesn't it need to be spelled out in some RFC
> that such a feature is crucial for certain things (esp. numerical
> multidim array passing) to make sure it's not dropped (for unrelated
> reasons) later on?
>
This feature is mentioned as required in RFCs 24, 81, 82, 90, and 91. More
generally, these RFCs specify that operations on lists should be carried out
lazily and without unnecessary array copies.
I think as long as we specify the features we need in our language RFCs, the
internals folks will identify the common threads needed to implement them.
This means that we should ensure that efficiency goals should be spelled out
in each RFC where it makes sense. For instance, from RFC 82:
<quote>
=head1 IMPLEMENTATION
These operators and functions should be evaluated lazily. For instance:
@b = (1,2,3);
@c = (2,4,6);
@d = (-2,-4,-6);
$sum = reduce ^_+^_, @b * @c + @d;
should be evaluated as if it read:
$sum = 0;
$sum += $b[$_] * $c[$_] + $d[_] for (0..$#a-1));
That is, no temporary list is created, and only one loop is required.
</quote>
