Austin Hastings writes:
> > ->Â @cp makes about as much sense as subÂ(@cp). C<outer> returns a
> > list of array references, right? So it binds each one to @cp (the right
> > of -> is a subroutine parameter list, remember?).
>
> Are you saying that subÂ(@cp) is not, in fact, an alias for C<map &sub, @cp> ?
>
> Anyway, I ask because I wonder what happens if @cp happens to contain some discrete
> number of elements that is not equal to the number returned by C<outer>?
>
> IOW:
>
> @cp = (1, 2, 3);
> for outer([0..255] xx 4) -> @cp {...}
>
> Does the current number of entries have any impact?
>
> for outer(@a, @b, @c) -> ($a, undef, $c) {...}
>
> Does that work?
Allow me to rewrite the loop to clarify. This has the exact same
semantic effect (as long as there is no C<return> within the loop
body), and pretty close to the same parse:
for outer(@a, @b, @c), sub (@cp) {...}
And now you can see that the previous contents of @cp don't mean
anything, because you're working with a different variable entirely. It
just happens to share the same name, but it's associated with a
different lexical scope.
The reason that:
for outer(@a, @b, @c) -> [$a, $b, $c] {...}
Works comes from Apocalypse 6, which states that a parameter list can be
placed in square brackets to indicate that an array is expected, and
that it will be decomposed as a separate, nested parameter list.
At first, I thought that was an unnecessary, bloating feature, but now I
see how marvelously useful it is :-)
Oh, by the way, this:
for outer([0..255] xx 4) -> @cp {...}
Needs to be written:
for outer(*[0..255] xx 4) -> @cp {...}
(Or even:
for outer(*([0..255] xx 4)) -> @cp {...}
depending on the precedence of unary *)
Luke
> > > I'm opposed to it: bad huffman coding.
> >
> > That's why it's a non-ascii operator. But I agree, there's really no
> > need for an operator here.
>
> And more to the point, the fact that we've "opened the (code) page"
> doesn't mean that we have an infinite supply of iso-latin-1 glyphs.
> We'd be prudent to conserve them.
>
> =Austin
>
