On Fri, Sep 03, 2004 at 02:56:48PM +0100, Peter Haworth wrote:
: 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.
That's exactly what the compiler does. There is now a class
of "list-associative" operators (to go with left-, right-,
and non-associative), and the yen "zipper" is one of them.
(By the way, they all came out question marks in your mail.)
Other list-associative operators are |, &, and ^.
: It also makes things harder for evil coders who want to define their own
: behaviour for ?.
Poor things...
: 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)).
Druther settle it at compile time...
: 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.
You can always say
zip(zip(@a, @b), @c)
: > 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?
That's correct.
Larry
