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 >