Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and "Jeremy Howard" <[EMAIL PROTECTED]>
whispered:
> | No. They are lazily evaluated and require special optimisations to allow
>
> I don't completely understand this whole lazy evaluation, so I'm confused
> how these functions would work on them. Explain to me how you would zip
> and unzip/partition sparse lists. For example, let's say I have list
like:
>
> $A[0] = 1, $A[2] = 5, $A[3] = 7, $A[5] = 11
> $B[1] = 4, $B[2] = 6, $B[4] = 10, $B[5] = 12
>
> How would these operators work on them?
>
Excellent question. I'm hand-waving around the internals issues at the
moment, because I'm concentrating on what the best outcome would look like,
so we then understand what explicit compromises we make as we come to
implementation.
At a language level, merge/unmerge/partition look no different applied to
sparse vs complete arrays. They act as if there are undefs in the undefined
locations (which there are, really).
However, the implementation of the functions is proposed to merely change
the array interface, not the internal storage. So the sparsity should be
untouched. Multiple levels of indirection (e.g. accessing a sparse array
through a slicing operator, and then partitioning) should be optimised away
into a single pointer. In C++ this is done using 'expression templates',
that use the template meta-language to describe the operations, which good
C++ compilers optimse away at compile time.
My expectation is the Perl will do more of this at run-time. Perhaps
candidates for loop unrolling and consolidation, and array index
consolidation could be identified at compile time, and when the lazily
applied functions and operators have to actually cohere to a real value,
Perl could be smart enough to optimise the operation at run-time.
