Consider the following:
Currently, this expresses all pairs of values of the members of
and
. This is in contrast to the meaning of NESL and Paralation
Lisp, where it means the elementwise extraction of items from
and
,
or to be more precise:
We don't care much for the above method of simultaneously stepping thru multiple sequences. We (claim to) support another form
but this is even stranger!
One alternative we considered was to make the iterators like NESL and add
define the operator between sequences to make the all-pairs
product. This would make
This seemed okay, until it was pointed out that the could only
yield rectangular structures (i.e., structures where each sequence of
values do not depend on other iterator values). This disallows the
expressions:
Not allowing these kinds of dependent iterators is as restrictive as not
allowing dependent nested for-loops, a rather severe restriction.
We come to the final suggestion. Leave the current scheme alone (each iterator generates its values for all previous iterators, possibly depending upon them), and add a zip function for elementwise enumeration. The zip operation is in many functional languages, so is as popular and well-understood as any of them (lisp, scheme, haskell). zip has the signature
[ ], [
] -> [(
)]
The zip function is overloaded to take an arbitrary number of
parameters (), and will zip all the sequences together in an
elementwise fashion. Elementwise add could then be written as
instead of
Compilers and interpreters do not have to implement zip as a function call, it can be an intrinsic that has a reasonable execution. Since it is not currently a built-in, here is an implementation
function zip(S, T) return [ i in [1..max(#S, #T)] : ( S(i), T(i) ) ];