&zip

[Rod Adams]

I'm trying to define zip(), but can't come up with a signature for a
function that returns a lazy list of lvalues, but the list itself is not
lazy?

As a second matter, can you declare a type for the elements of a slurpy
array?

So far I have:

multi sub zip (Array *@lists) returns List {
gather {
while any(@lists) {
for @lists -> @list {
take shift @list;
}
}
}
}

But I can't tackle the lvalue problem.

btw, I'm defining the semantics of some of several functions by simply
supplying a reference implementation.

[Larry Wall]

On Tue, Mar 15, 2005 at 02:47:33AM -0600, Rod Adams wrote:
: I'm trying to define zip(), but can't come up with a signature for a

: function that returns a lazy list of lvalues, but the list itself is not
: lazy?

If we go with my once-upon-a-time notion of using zip(@a;@b), then it
naturally comes in as [@a],[@b].

: As a second matter, can you declare a type for the elements of a slurpy
: array?

Yes, and it distributes as any array return type declaration would.

: So far I have:

:
: multi sub zip (Array *@lists) returns List {
: gather {
: while any(@lists) {

any() is not guaranteed to produce left-to-right order.

: for @lists -> @list {

: take shift @list;
: }
: }
: }
: }
:
: But I can't tackle the lvalue problem.

Why do they need to be lvalues? I always thought of zip as non-destructive.
Has zip historically been destructive in other languages?

: btw, I'm defining the semantics of some of several functions by simply
: supplying a reference implementation.

That's cool.

Larry

[Rod Adams]

Larry Wall wrote:

>If we go with my once-upon-a-time notion of using zip(@a;@b), then it
>naturally comes in as [@a],[@b].
>
>

It pretty much has to use the list of lists syntax, since the number of
Arrays we are zipping is variadic, and that means using a slurpy, which
would flatten the arrays into one. So the semicolons stay. Unless
there's a non-flattening slurpy syntax out there....

>: As a second matter, can you declare a type for the elements of a slurpy
>: array?
>
>Yes, and it distributes as any array return type declaration would.
>
>

Does this mean that we can define multiple slurpuy arrays (and
hashes?!?) in a parameter list, of different types, and Perl will sort
the arguments into the right slurpy for us? If so, how does this
interact with the answer about C<@CALLER::_>?

>: So far I have:
>:
>: multi sub zip (Array *@lists) returns List {
>: gather {
>: while any(@lists) {
>
>any() is not guaranteed to produce left-to-right order.
>
>

I'm not counting on it being ordered. I'm testing to see if any of the
lists still has anything left in it. The left to right-ness of the
processing is done in the C<for>.

>: for @lists -> @list {
>: take shift @list;
>: }
>: }
>: }
>: }
>:
>: But I can't tackle the lvalue problem.
>
>Why do they need to be lvalues? I always thought of zip as non-destructive.
>Has zip historically been destructive in other languages?
>
>

I wasn't aware of a C<zip> in other languages.

My thought was that people might want to update the values stored
inside, as an homage to my common Perl 5 construct:

for ($var1, $var2) {
s/.../.../;
s/.../.../;
}

(and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to:

for $var1, $var2 -> $_ is rw {
s/.../.../;
s/.../.../;
}

though

given $var1 {
s/.../.../;
s/.../.../;
}

is nice.

)

But if you don't see the need for lvalueing the elements coming out of
C<zip>, that certainly makes things easier. :-)

-- Rod Adams

[Larry Wall]

On Wed, Mar 16, 2005 at 01:48:27PM -0600, Rod Adams wrote:
: Larry Wall wrote:
: >Yes, and it distributes as any array return type declaration would.

: >
: >
: Does this mean that we can define multiple slurpuy arrays (and
: hashes?!?) in a parameter list, of different types, and Perl will sort
: the arguments into the right slurpy for us? If so, how does this
: interact with the answer about C<@CALLER::_>?

No, I just meant that

Foo *@array

applies the Foo as the type of the elements of @array despite the
presence of the *.

: I'm not counting on it being ordered. I'm testing to see if any of the

: lists still has anything left in it. The left to right-ness of the
: processing is done in the C<for>.

Oh, right--I'd better learn to read Perl 6 one of these days. :-)

: My thought was that people might want to update the values stored

: inside, as an homage to my common Perl 5 construct:
:
: for ($var1, $var2) {
: s/.../.../;
: s/.../.../;
: }
:
:
: (and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to:
:
: for $var1, $var2 -> $_ is rw {
: s/.../.../;
: s/.../.../;
: }
:
: though
:
: given $var1 {
: s/.../.../;
: s/.../.../;
: }
:
: is nice.
:
: )

Well paint yourself unchagrined, because S04 sez:

Parameters are by default constant within the block. You can
declare a parameter read/write by including the "is rw" trait. If
you rely on $_ as the implicit parameter to a block, then then $_
is considered read/write by default. That is, the construct:

for @foo {...}

is actually short for:

for @foo -> $_ is rw {...}

so you can modify the current list element in that case. However,
any time you specify the arguments, they default to read only.

Larry

[Rod Adams]

Larry Wall wrote:

>Well paint yourself unchagrined, because S04 sez:
>
> Parameters are by default constant within the block. You can
> declare a parameter read/write by including the "is rw" trait. If
> you rely on $_ as the implicit parameter to a block, then then $_
> is considered read/write by default. That is, the construct:
>
> for @foo {...}
>
> is actually short for:
>
> for @foo -> $_ is rw {...}
>
> so you can modify the current list element in that case. However,
> any time you specify the arguments, they default to read only.
>
>
>

< gets out unchagrining paint and splashes it about. :-) >

You know, the amazing thing about those Synopses and Apocalypses you
wrote is that no matter how many times I read them, I always find 5 new
things in them on each pass. And I'm the kind of guy who typically
absorbs entire 200 page reference manuals in one pass. I swear you found
the English equivalent of Quantum Mechanics in there, where entire
paragraphs exist and don't exist at the same time, without changing. :-)

Of course, I now have to question the need for C<given>. Other than
linguistics, which is not to be dismissed, what difference is there between

given $expr { ... }

and

for $expr { ... }

with equivalent ...'s?

hmm. Come to think of it, the C<for> would flatten $expr if it happened
to look like an array or something equally "bumpy", where C<given> would
not. But perhaps it would make sense to define C<for> and C<given> as
synonyms in all other ways but "autoflatten".

As far as linguistics go, "for" makes a suitable replacement for "given"
in my head. It's just a very heavily loaded term when you leave English
and enter CS-speak.

-- Rod Adams

[Juerd]

Larry Wall skribis 2005-03-16 12:17 (-0800):

> for @foo {...}
> is actually short for:
> for @foo -> $_ is rw {...}

Has there been any decision on <-> yet? If <-> is there, it's much
easier to say that without arguments, <-> $_ is used. That way, there is
no surprising magic "is rw", but just another operator (that happens to
be the exact same thing in practice).

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

[Larry Wall]

On Wed, Mar 16, 2005 at 02:55:21PM -0600, Rod Adams wrote:
: Of course, I now have to question the need for C<given>. Other than

: linguistics, which is not to be dismissed, what difference is there between
:
: given $expr { ... }
:
: and
:
: for $expr { ... }
:
: with equivalent ...'s?
:
: hmm. Come to think of it, the C<for> would flatten $expr if it happened
: to look like an array or something equally "bumpy", where C<given> would
: not. But perhaps it would make sense to define C<for> and C<given> as
: synonyms in all other ways but "autoflatten".

We considered this at one point, but in addition to the difference
between list and scalar context, there's also the fact that the
inside responds differently to "next" and "last". A "given" is
officially NOT a loop, so "next" and "last" escape from it to whatever
the outer loop is.

Larry