Next: Notes on Allowing Up: The Proteus NS Grammar Previous: Statements

Notes on Multiple Iterators

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) ) ];

Next: Notes on Allowing Up: The Proteus NS Grammar Previous: Statements
Wed Aug 31 15:43:33 EDT 1994