Larry Wall writes:
> Currently it does. There have been some rumblings in the design team
> that maybe it shouldn't. But it occurs to me that this might be another
> spot to have our cake and eat it to. We could say that
>
> for @foo -> $input { ... $input ... }
>
> doesn't set the topic in the block by default. However, methods do set
> the topic (though there have been rumblings about that too). So we could
> simply say that pointy subs can also be pointy methods if you specify
> an invocant:
>
> for @foo -> $input: { ... $input and $_ ... }
>
> I think I like that, but it needs to be thunk about some more. The downside
> is that it's rather subtle. The upside is that it falls out of existing
> rules, and lets -> map more naturally in the way people expect. I don't
> think people will naturally expect -> to clobber $_.
Considering that I was the rumbler, I'll try to stay concise. Don't
think that this is anything more than a stormy brain, though.
I really like the fact that for always topicalizes. I like it because
it forces refactors where they ought to be happening. I always get
confused when I see:
for (@array) {
for my $row (@{$data->[$_]}) {
for my $element (@$row) {
foobar($_) if $element;
}
}
}
It works that way in natural languages too. If you try to use "it" too
remotely, you just confuse everybody. In particular:
For each element in @array, look up the corresponding $row in $data,
and for each $element in the $row, call foobar on it if $element is
true.
Call foobar on what?
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (&oper) {
&oper($.left);
&oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (&oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Luke
