On Thu, Jun 16, 2005 at 05:40:31PM +0800, Autrijus Tang wrote:
: Currently in Pugs &*zip has no signature -- it simply rewrites its
: arguments into the listfix ￥ (i.e. Y) function.
:
: That is bad because it can't be introspected, and you can't define
: something like that yourself. It also makes it uncompilable to Parrot
: as I don't control the runloop there. :)
I think something like
sub zip (Pipe [EMAIL PROTECTED]) {...}
is probably sufficient.
The semicolon operator no longer builds a list of lists, but a list
of pipes, which are specially marked Lazies that know they came from
pipe operators (including semicolons as a kind of pipe operator).
When bound to an ordinary splat array (or in fact any splat array whose
type isn't Pipe), the Pipes flatten as if they were comma separated.
When bound to an array of type Pipe, each pipe stays discrete.
: Also, currently the following code does not flatten @a and @b together,
: which I'm not exactly sure is correct or not:
:
: zip(@a, @b);
That should flatten into a single slice/pipe, so zip should probably
have the option of complaining about it somehow. On the other hand,
you don't want warnings for the default on any such binding, since
subscripts use the same binding, and we'll often have subscripts with
a single slice.
We also have this construct to allow indirect semicolon lists:
zip( [;] @lists )
(The [;] reduction operator takes the place of "semi" in S09.)
This does imply that we can pipe into a subscript somehow. If we
choose something like () for our placeholder meaning "pipe into this
location", then
@[EMAIL PROTECTED]; @b; @c]
is the same as
@foo[()] <== @a <== @b <== @c
or
@c ==>
@foo[()] <== @a <== @b
or
@c ==>
(@b ==>
@foo[()] <== @a
)
or
@c ==>
(@b ==>
(@a ==>
@foo[()]
)
)
though perhaps there's some ambiguity problems with using a single ()
as the target of multiple ==>. Note that every list has an implied ()
at the end, which is the default target of pipe operators. That says
to me that we probably make a rule that ==> binds to the leftmost ()
it sees (if it sees one), so we can differentiate
@a ==>
@foo[$x].print()
from
@a ==>
@foo[()].print
And in the absence of an explicit (), the rightmost implicit () is
the target, so
@a ==>
@foo[$x].print
should feed the pipe to the print, not the subscript, even though
$x is officially part of a one-element slice with an implicit ()
at the end. I think this is closest to what people will expect.
Larry
