On Thu, 19 Aug 2004 19:45:37 -0700, Larry Wall wrote:
> To process two arrays in parallel, use either the zip function:
>
> for zip(@a,@b) -> $a, $b { print "[$a, $b]\n" }
>
> or the "zipper" operator to interleave them:
>
> for @a ¥ @b ¥ @c -> $a, $b, $c { print "[$a, $b, $c]\n" }
n-ary zip() is simple enough, but the infix ¥ makes zipping more than
two lists somewhat entertaining. Without iterators doesn't work well:
@a ¥ @b produces (@a[0],@b[0],@a[1],@b[1],...)
which is what we wanted, but
@a ¥ @b ¥ @c produces (@a[0],@c[0],@b[0],@c[1],@a[1],@c[2],@b[1],...)
which isn't. The compiler *could* be made to detect such cases, and
turn them into
zip(@a,@b,@c)
but that seems like piling even more onto the poor compiler's
plate, which already has to be the size of the whole table. It also
makes things harder for evil coders who want to define their own
behaviour for ¥.
If we implement ¥ as an iterator (which is surely the plan), we can
get more fancy. With two lists as arguments, we return zip(@a,@b), and
if either argument is itself a zip iterator, we decompose it to get
the original lists, and return zip(*lists_from(@a),*lists_from(@b)).
Great. But what if what you actually wanted was the horrible thing
that the naive non-iterator approach gives you with three lists? Do
you have to say this instead?
*(@a ¥ @b) ¥ @c
Yuck, that's two thirds of the iteration benefit lost, or all of it if
either of @a or @b are infinite.
> A C<return> always exits from the lexically surrounding sub or
> method definition (that is, from a function officially declared with
> the C<sub>, C<method>, or C<submethod> keywords). Pointy subs and
> bare closures are transparent to C<return>. If you pass a reference
> to a closure outside of its official "sub" scope, it is illegal to
> return from it.
Presumably this illegality only applies to closures not officially
declared as subs, methods or submethods?
--
Peter Haworth [EMAIL PROTECTED]
"Her vocabulary was as bad as, like, whatever."
