In the future, it would be nice to be able to zip a finite stream with an infinite one. Attempt the problem that @bradcray had mentioned on gitter...
"If you want a challenge to work on, invent a revised leader/follower interface that efficiently supports (a) a reasonable error message for forall (i,j) in zip(1..3, 1..6) and (b) the ability to maintain a cursor for a conceptually infinite follower like a random stream or file channel (i.e., one that supports forall (i,j) in zip(1..n, myStream) followed by forall (i,j) in zip(1..n, myStream) and doesn’t return the same n values each time, but items n+1..2*n the second time)."
"The challenge is this: You’re writing a follower iterator with the current interface. Four leader tasks call it, each requesting its corresponding n/4 chunk of items. How/where/when do you update the stream’s global cursor to indicate that n elements have been consumed so that the next time k leader tasks call it requesting n/k chunks, it continues where it left off? The current interface makes this somewhere between hard and impossible because there’s no cooperation between individual calls to the follower iterators.
(Ditto for case (a) where each follower yields what was requested, but nobody ever has the global picture to see that only a subset of the finite items were requested and that a size mismatch error should be generated)."
"Create a counter() iterator that when zipped with 1..n will return the integers 1..n in sorted order (maybe assign them to an n-element array to be sure). And then when zipped a second time returns the integers n+1..2*n in sorted order."
Something like this is relevant to CHGL in that zippered iteration is a fundamental parallel language construct, and any improvements on this area will help not only CHGL but Chapel in general.
Paper on "User-Defined Parallel Zippered Iterators" can be seen here: http://pgas11.rice.edu/papers/ChamberlainEtAl-Chapel-Iterators-PGAS11.pdf