> 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
