> Austin Hastings wrote: > > > I'm way not sure about how the vector context result of iteration > structures > > will work. Specifically, what happens when a loop forks a thread, or > passes > > to a parallelized coroutine? There may not actually BE a result. (Of > course, > > in a right-thinking system this will be noted, and replaced by a > placeholder > > object that will "wait" for the result if evaluated.) > > Whuh? Tangential at best... The result would be the same as in a > non-vectorized version, just repeated automatically for you.
Would EVENTUALLY be the same as ... Sure. The whole iterator/generator thing has already been covered, so I'm pretty sure we've got the underpinnings. > my @b = for @a -> $_ { > ... > } > > Should be broadly equivalent to: > > my @b = map { ... } @a; > > - OR - > > # (Apologies for the perl5-isms.) > for @a -> $_ { > push @b: do { ... }; > } Yes. I think I made that point lower down. In fact, the "collector" behavior of evaluating for in a vector context should help people transition from C<for> to C<map>. (Only Satan, or his handpicked successor Damian, will help them get from there to C<any>/C<none>, however. :-) > If the non-vectorized version has hidden a thread join operation in a > tied or otherwise magical result value, then so too would the vectorized > version. But that's a completely orthogonal feature; unrelated and not > in conflict. True, but of course the scalar version doesn't have to wait for the results. =Austin