[perl6/specs] 216855: [S04] Add missing parenthesis in zip() example
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 2168554941a2c85b7c3a1512382a965aa3139258 https://github.com/perl6/specs/commit/2168554941a2c85b7c3a1512382a965aa3139258 Author: Sterling Hanenkamp Date: 2016-01-16 (Sat, 16 Jan 2016) Changed paths: M S04-control.pod Log Message: --- [S04] Add missing parenthesis in zip() example Commit: 21525aab69789f0d7a00640d75ae332d4fad9e73 https://github.com/perl6/specs/commit/21525aab69789f0d7a00640d75ae332d4fad9e73 Author: niner Date: 2016-01-17 (Sun, 17 Jan 2016) Changed paths: M S04-control.pod Log Message: --- Merge pull request #105 from zostay/zip-parens [S04] Add missing parenthesis in zip() example Compare: https://github.com/perl6/specs/compare/b0657be1c92e...21525aab6978
[perl6/specs] 2a277a: spec zip-latest
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 2a277a7b5199eaca0b1ceeb5fb5c35b474b3cf39 https://github.com/perl6/specs/commit/2a277a7b5199eaca0b1ceeb5fb5c35b474b3cf39 Author: Timo Paulssen Date: 2014-06-14 (Sat, 14 Jun 2014) Changed paths: M S17-concurrency.pod Log Message: --- spec zip-latest
[perl6/specs] f143d1: Supply.(zip|merge) can be called as class method
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: f143d1a0644a28e1bd63aeb990f2f95f2ea33f47 https://github.com/perl6/specs/commit/f143d1a0644a28e1bd63aeb990f2f95f2ea33f47 Author: Elizabeth Mattijsen Date: 2014-04-20 (Sun, 20 Apr 2014) Changed paths: M S17-concurrency.pod Log Message: --- Supply.(zip|merge) can be called as class method
[perl6/specs] 05ea68: Add examples for Supply.(merge|zip)
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 05ea68b3698a342c383290a515fc99cb85de4273 https://github.com/perl6/specs/commit/05ea68b3698a342c383290a515fc99cb85de4273 Author: Elizabeth Mattijsen Date: 2014-04-19 (Sat, 19 Apr 2014) Changed paths: M S17-concurrency.pod Log Message: --- Add examples for Supply.(merge|zip)
[perl6/specs] 62b8b3: [S03] Fix ttiars in Zip operators
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 62b8b3936044787ee6124f0712ada152a0d82107 https://github.com/perl6/specs/commit/62b8b3936044787ee6124f0712ada152a0d82107 Author: Tadeusz Sośnierz Date: 2011-06-11 (Sat, 11 Jun 2011) Changed paths: M S03-operators.pod Log Message: --- [S03] Fix ttiars in Zip operators
Re: Zip more than two arrays?
On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote:
: However, if I get my wish of having zip return tuples, then it can be
: left-associative. But since it interleaves instead, making it left-
: or right-associative gives strange, incorrect results.
I expect zip ought to bundle up into tuples of some sort. But then
maybe zip is not what we want for typical loops. I'm thinking that
"for" wants to be a little more incestuous with -> anyway, so that
the optionality of the -> arguments can tell "for" how to deal with
short lists. And now that we have general multidimensional slices,
it'd be nice if "for" were one of the operators that is aware of that.
Then you might be able to say things like:
for (@foo; 1...) -> $val, $i {...}
for @foo <== 1... -> $val, $i {...}
1... ==>
for @foo -> $val, $i {...}
1... ==> ###v
@foo ==> #v v
for () -> $val, $i {...}
all of which should in theory be equivalent, and none of which use "zip".
(With a bit of handwaving about how ==> binds to the list before
a final -> block.)
With a clever enough parser, we even get back to the A4 formulation of
for @foo; 1... -> $val, $i {...}
But that's relying on the notion that a statement can function as a
funny kind of bracketing device that can shield that semicolon from
thinking it's supposed to terminate the statement. That's probably
not too far off from what it does now when it knows it wants a final
block, so that a bare block where an operator is expected pops back
up to the statement level.
I know that, with tuple matching signatures, zip can be made to work
even as a tuple constructor, but it seems like a waste to constuct
tuples only to throw them away immediately. And if we're going to
build surreal lists into the language, we should probably use them.
Larry
Re: Slightly OT: zip() for Perl5?
At 5:32 PM -0400 10/21/05, Mark Reed wrote: Is there a CPAN module which provides the functionality of ¥/zip() for Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard to write, of course, just wondering if it's been done . . . The List::MoreUtils CPAN module does provide this, and is cited in Perl Best Practices as doing so also. -- Darren Duncan
Re: Slightly OT: zip() for Perl5?
Does TYE's Algorithm::Loops's mapcar() provide the basic functionality of what you're looking for? Rob On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote: > Is there a CPAN module which provides the functionality of ¥/zip() for > Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard > to write, of course, just wondering if it's been done . . . > > > >
Re: Zip more than two arrays?
On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote:
> Hm. This brings up another point, which may have been addressed . . .
>
> The Python function and Ruby array method zip() both accept any number of
> arrays to interleave:
>
> >>> zip([1,2,3],[4,5,6],[7,8,9])
> [(1, 4, 7), (2, 5, 8), (3, 6, 9)]
>
> irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9])
> => [[1, 4, 7], [2, 5, 8], [3, 6, 9]]
>
> How would you write the above in Perl6, given that ¥/Y is an infix operator?
Ah, ¥ is not a binary infix operator. Instead, it is what Damian
calls "list-associative". Another such operator is junctive ^, for if
it were binary, it would be an xor, not a one.
As far as the syntax goes, well, we'll have to make some up.
sub listfix:<¥> (Array [EMAIL PROTECTED]) {...}
sub infix:<¥> is assoc('list') (Array [EMAIL PROTECTED]) {...}
Or something like that.
However, if I get my wish of having zip return tuples, then it can be
left-associative. But since it interleaves instead, making it left-
or right-associative gives strange, incorrect results.
Luke
Zip more than two arrays?
Hm. This brings up another point, which may have been addressed . . . The Python function and Ruby array method zip() both accept any number of arrays to interleave: >>> zip([1,2,3],[4,5,6],[7,8,9]) [(1, 4, 7), (2, 5, 8), (3, 6, 9)] irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9]) => [[1, 4, 7], [2, 5, 8], [3, 6, 9]] How would you write the above in Perl6, given that ¥/Y is an infix operator? On 2005-10-21 5:32 PM, "Mark Reed" <[EMAIL PROTECTED]> wrote: > Is there a CPAN module which provides the functionality of ¥/zip() for > Perl5?
Slightly OT: zip() for Perl5?
Is there a CPAN module which provides the functionality of ¥/zip() for Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard to write, of course, just wondering if it's been done . . .
Re: zip: stop when and where?
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> for @foo Y @bar Y @baz -> $quux, $xyzzy { ... }
>
> is something you will probably not see very often, it's still legal
> Perl, even though it looks asymmetric. This too makes finding the
> solution in arguments a non-solution.
Don't be silly. There's no reason we can't break that; it's not an
idiom anybody is counting on. If you still want the behavior:
for flatten(@foo Y @bar Y @baz) -> $quux, $xyzzy {...}
But your point about Y returning a list and therefore not being
for-specific is quite valid.
Luke
Re: zip: stop when and where?
Dave Whipp skribis 2005-10-06 9:57 (-0700):
> Given that my idea about using optional binding for look-ahead didn't
> fly, maybe it would work here, instead:
> @a Y @b -> $a, $b { ... } # stop at end of shortest
> @a Y @b -> $a, ?$b { ... } # keep going until @a is exhaused
> @a Y @b -> ?$a, ?$b { ... } # keep going until both are exhaused
> I think we still need a way to determine if an optional arg is bound.
> Can the C function be used for that ("if exists $b {...}")?
Y isn't something that is specific to for loops, or to sub invocation,
so this cannot be a solution.
Also remember that Y creates a single flattened list by definition, and
that the given sub's arity determines how many items of that list are
used.
It's perfectly legal and possibly even useful to say
for @foo, @bar, @baz -> $quux, $xyzzy { ... }
And even though
for @foo Y @bar Y @baz -> $quux, $xyzzy { ... }
is something you will probably not see very often, it's still legal
Perl, even though it looks asymmetric. This too makes finding the
solution in arguments a non-solution.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: zip: stop when and where?
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
> If we make zip return a list of tuples rather than an interleaved
> list, we could eliminate the final 1/3 of those errors above using the
> typechecker. That would make the for look like this:
>
> for @a Y @b -> ($a, $b) {...}
I like it (I think). I'm not sure about the syntax though. Is this one
of those places where round brackets are equivalent to square brackets?
I.e., would this be the same:
for @a ¥ @b -> [$a,$b] { ... }
?
Also, it seems like this syntax would almost always require the brackets
to be correct. Most of the time people will see and expect for loops
that look like this:
for MUMBLE -> $a, $b { ... }
Except now they've probably got a semantic error when MUMBLE contains ¥
or is prefixed by zip. This type of error mayn't be so easy to detect
depending on what they're mumbling about.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: zip: stop when and where?
Luke Palmer wrote:
zip :: [a] -> [b] -> [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a "b" unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] -> [b] -> [(Maybe a, Maybe b)]
Anyway, that's just more of the usual Haskell praise.
Given that my idea about using optional binding for look-ahead didn't
fly, maybe it would work here, instead:
@a Y @b -> $a, $b { ... } # stop at end of shortest
@a Y @b -> $a, ?$b { ... } # keep going until @a is exhaused
@a Y @b -> ?$a, ?$b { ... } # keep going until both are exhaused
I think we still need a way to determine if an optional arg is bound.
Can the C function be used for that ("if exists $b {...}")?
Dave.
Re: zip: stop when and where?
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
> > I'm just wondering why you feel that we need to be so careful.
>
> Because I can think of at least three reasonable and useful default behaviours
> for zipping lists of differing lengths:
>
> # Minimal (stop at first exhausted list)...
> for @names ¥ @addresses -> $name, $addr {
> ...
> }
>
>
> # Maximal (insert undefs for exhausted lists)...
> for @finishers ¥ (10..1 :by(-1)) -> $name, $score {
> $score err next;
> ...
> }
>
>
> # Congealed (ignore exhausted lists)...
> for @queue1 ¥ @queue2 -> $server {
> ...
> }
>
> Which means that there will be people who expect each of those to *be* the
> default behaviour for unbalanced lists.
Perhaps that makes sense. That certainly makes sense for other kinds
of constructs. Something makes me think that this is a little
different. Whenever somebody asks what "Y" is on #perl6, and I tell
them that it interleaves two lists, a follow-up question is *always*
"what does it do when the lists are unbalanced." Now, that may just
be a behavior of #perl6ers, but I'm extrapolating. It means that
there isn't an assumption, and if they weren't #perl6ers, they'd RTFM
about it.
When I learned Haskell and saw zip, I asked the very same question[1].
I was about as comfortable writing Haskell at that point as beginning
programmers are with writing Perl, but it still took me about ten
seconds to write a test program to find out. The rest of Perl doesn't
trade a reasonable default behavior for an error, even if it *might*
be surprising the first time you use it. It doesn't take people long
to discover that kind of error and never make that mistake again.
If we make zip return a list of tuples rather than an interleaved
list, we could eliminate the final 1/3 of those errors above using the
typechecker. That would make the for look like this:
for @a Y @b -> ($a, $b) {...}
An important property of that is the well-typedness of the construct.
With the current zip semantics:
my A @a;
my B @b;
for @a Y @b -> $a, $b {
# $a has type A (+) B
# $b has type A (+) B
}
With tuple:
my A @a;
my B @b;
for @a Y @b -> ($a, $b) {
# $a has type A
# $b has type B
}
Which is more correct. No... it's just correct, no superlative
needed. It also keeps things like this from happening:
for @a Y @b -> $a, $b {
say "$a ; $b"
}
# a1 b1
# a2 b2
# a3 b3
# ...
"Oh, I need a count," says the user:
for @a Y @b Y 0... -> $a, $b { # oops, forgot to add $index
say "$a ; $b"
}
# a1 b1
# 0 a2
# b2 1
# ...
Luke
[1] But I didn't need to. The signature told me everything:
zip :: [a] -> [b] -> [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a "b" unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] -> [b] -> [(Maybe a, Maybe b)]
Anyway, that's just more of the usual Haskell praise.
Re: zip: stop when and where?
Luke wrote:
>>Once C stops zipping, if any other element has a known finite
>>number of unexhausted elements remaining, the fails.
>
> Wow, that's certainly not giving the user any credit.
Actually, I want to be careful because I give the users too much credit. For
imagination.
> I'm just wondering why you feel that we need to be so careful.
Because I can think of at least three reasonable and useful default behaviours
for zipping lists of differing lengths:
# Minimal (stop at first exhausted list)...
for @names ¥ @addresses -> $name, $addr {
...
}
# Maximal (insert undefs for exhausted lists)...
for @finishers ¥ (10..1 :by(-1)) -> $name, $score {
$score err next;
...
}
# Congealed (ignore exhausted lists)...
for @queue1 ¥ @queue2 -> $server {
...
}
Which means that there will be people who expect each of those to *be* the
default behaviour for unbalanced lists. Which means there shouldn't be any
default for unbalanced lists, since whatever that default is won't DWIM for
2/3 of the potential users. Which means that unbalanced lists ought to produce
an error, unless the user specifies how to deal with the imbalance.
Damian
Re: zip: stop when and where?
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote: > So I now propose that C works like this: > > C interleaves elements from each of its arguments until > any argument is (a) exhausted of elements I (b) doesn't have > a C property. > > Once C stops zipping, if any other element has a known finite > number of unexhausted elements remaining, the fails. Wow, that's certainly not giving the user any credit. I'm just wondering why you feel that we need to be so careful. Luke
Re: zip: stop when and where?
David Storrs asked:
If you want a multiway zip with
differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
I don't think that works. For example, why does the :fill(0) of the first ¥
apply to the 1..10 argument instead of to the 'a'..'c' argument? Especially
when it's the 'a'..'c' argument that's the shorter of the two!
Besides which, adverbs, being optional, come at the end of an operator's
argument list. Moreover, it's unclear to me where how they are applied at all
to an n-ary operator like ¥.
On top of which, even if it did work, that formulation doesn't help at all if
you don't have Unicode available and are therefore forced to use C.
Assuming, of course, that it is possible to stick an adverb on the op
as I was requesting.
My recollection is that $Larry has previously said that this is not the
case...that adverbs are suffixed.
Damian
Re: zip: stop when and where?
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on C is a suboptimal solution,
because it implies that you would always want to fill in *any* gap
with the same value. While that's likely in a two-way zip, it seems
much less likely in a multiway zip.
I actually have no problem with the solution you suggest (although I
rather like my idea about being able to 'fill in' with a control
exception), but I do have a question. If you want a multiway zip
with differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
Assuming, of course, that it is possible to stick an adverb on the op
as I was requesting.
--Dks
Re: zip: stop when and where?
I've been thinking about this issue some more and it occurs to me that we
might be thinking about this the wrong way.
Providing a :fillin() adverb on C is a suboptimal solution, because it
implies that you would always want to fill in *any* gap with the same value.
While that's likely in a two-way zip, it seems much less likely in a multiway zip.
So I now propose that C works like this:
C interleaves elements from each of its arguments until
any argument is (a) exhausted of elements I (b) doesn't have
a C property.
Once C stops zipping, if any other element has a known finite
number of unexhausted elements remaining, the fails.
In other words, you get:
@i3 = 1..3 ;
@i4 = 1..4 ;
@a3 = 'a'..'c' ;
zip(@a3, @i3) # 'a', 1, 'b', 2, 'c', 3
zip(@i3, @i4) # fail
zip(100..., @a3, @i3) # 100, 'a', 1, 101, 'b', 2, 102, 'c', 3
zip(100..., @a3, @i4) # fail
zip(@a3 but fill(undef), @i4) # 'a', 1, 'b', 2, 'c', 3, undef, 4
zip(1..6, @i3 but fill(3), @i4 but fill('?'))
# 1,1,1,2,2,2,3,3,3,4,3,4,5,3,'?',6,3,'?'
Damian
Re: zip: stop when and where?
I guess nobody mentioned this, so I don't know how people on perl-language feel about 'do it the same was as ', but I took a small jump into Haskell a while back (barely enough to consider myself a beginner), but even after just a little bit of time with it, I think I'd almost expect the default zip behavior to stop zipping after the least amount of elements. On 10/5/05, Juerd <[EMAIL PROTECTED]> wrote: > > Damian Conway skribis 2005-10-05 10:05 (+1000): > > I suspect that the dwimmiest default would be for C to stop zipping > at > > the length of the shortest finite argument. And to fail unless all > finite > > arguments are of the same length. > > This is a nice compromise. > > But what if you cannot know whether a list is finite? > > my @foo = slurp ...; # lazy, but can be either finite or infinite > my @bar = 1..10; > > say @foo Y @bar; # ? > > > Juerd > -- > http://convolution.nl/maak_juerd_blij.html > http://convolution.nl/make_juerd_happy.html > http://convolution.nl/gajigu_juerd_n.html >
Re: zip: stop when and where?
Damian Conway skribis 2005-10-05 10:05 (+1000): > I suspect that the dwimmiest default would be for C to stop zipping at > the length of the shortest finite argument. And to fail unless all finite > arguments are of the same length. This is a nice compromise. But what if you cannot know whether a list is finite? my @foo = slurp ...; # lazy, but can be either finite or infinite my @bar = 1..10; say @foo Y @bar; # ? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: zip: stop when and where?
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = ('a', 'b', 'c');
for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5
undef 6
for @foo ¥ 1..6 :fillin('') # a 1 b 2 c 3 '' 4 '' 5 '' 6
for @foo ¥ 1..6 :fillin(0)# a 1 b 2 c 3 0 4 0 5 0 6
for @foo ¥ 1..6 :fillin(return) # same as: return ('a', 1, 'b', 2
'c', 3);
A couple of things bother me about this, though:
- Bad endweight on the adverb. It looks like you are modifying the
second list, not the ¥ op
That's because you are.
Good. That makes sense. I did it this way because it seemed like
others on the thread were doing it this way...but it felt wrong at
the time. Glad to see my intuition is not totally useless.
for @foo ¥ 1..6 :fillin(last) # a 1 b 2 c 3
Uh, I don't think that works.
I know it doesn't, I was proposing it as new functionality. The idea
in my head was a bit fuzzy and I probably should have crystallized it
before writing. Had I done so, it might have come out as something
more like this:
@foo = ;
for @foo ¥ 1..6 :fillin(undef)
# a 1 b 2 c 3 undef 4 undef 5 undef 6
for @foo ¥ 1..6 :fillin('x')
# a 1 b 2 c 3 x 4 x 5 x 6
for @foo ¥ 1..6 :fillin(exception but last)
# a 1 b 2 c 3
FOR_LOOP:for @foo ¥ 1..6 :fillin(exception but last FOR_LOOP)
# zips the lists, never enters the for loop body
for @foo ¥ 1..6 :fillin(exception but return)
# same as: return ; i.e., it returns from a sub
Perhaps 'exception' is spelled 'fail' or 'die' or something like that.
Off the top of my head, I can't think of why you would want to use
the 'exception but return' that I show above--it would return from
the enclosing subroutine, without ever entering the loop body. It
would be a highly obfuscated way to return. However, my
understanding of the current design is that 'return' is just an
exception with a built-in handler, so this is a logical corner case
of what I'm suggesting.
Could something like this syntax be made to work?
for (@foo ¥:fillin(undef) 1..6) but true # a but true, 1 but
true...undef but true, 6 but true
I think you've stumbled upon the reason why we made adverbs come
after
operators.
I'm not quite sure how you are using 'come after operators' here,
since in both of the following the adverb comes after the op (it's
just that in the second, there's something between them):
for (@foo) Y (1..6) :fillin(undef) {...}
for (@foo ¥:fillin(undef) 1..6){...}
The important thing is the zip, not the fact that you're
filling in with undef.
I would phrase it as "the important thing is what you are doing with
the lists". That encompasses both the operator you are using (zip)
and how that operator will behave (fill in with, in this case, undef).
--Dks
Re: zip: stop when and where?
On Tue, 4 Oct 2005, Eric wrote: I'd just like to say that I find B a bit misleading because you couldn't tell that the first list ended, it could just have undef's at the end. I Well, OTOH undef is now a more complex object than it used to be, so there may be cheap workarounds. Of course one would still like reasonable defaults and dwimmeries on commonly used idioms... Michele -- Darl MacBride, is that you? They said over at Groklaw that the folks at SCO were trying to discredit Open Source. SCO, a company traditionally run by Mormons, but they had to downsize the second m? Well, they still have M for capital. - David Kastrup in comp.text.tex, "Re: Is Kastrup..."
Fwd: zip: stop when and where?
Both Luke and I missed the fact that my mail and his response went
only to each other so, with his permission, here it is as a forward.
--Dks
Begin forwarded message:
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = ('a', 'b', 'c');
for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5
undef 6
for @foo ¥ 1..6 :fillin('') # a 1 b 2 c 3 '' 4 '' 5 '' 6
for @foo ¥ 1..6 :fillin(0)# a 1 b 2 c 3 0 4 0 5 0 6
for @foo ¥ 1..6 :fillin(return) # same as: return ('a', 1, 'b', 2
'c', 3);
A couple of things bother me about this, though:
- Bad endweight on the adverb. It looks like you are modifying the
second list, not the ¥ op
That's because you are. I can't seem to find the document that
describes this, but as far as I recall (and my memory may be fuzzy
here), infix operators with adverbs look roughly like this:
rule infixop {? }
Where is, of course, greedy. So since .. is tighter than Y:
for @foo Y 1..6 :fillin(undef) {...}
Is equivalent to:
for @foo Y (1..6 :fillin(undef)) {...}
And to get it modifying Y you need to do:
for (@foo) Y (1..6) :fillin(undef) {...}
(Parens added around @foo for symmetry).
for @foo ¥ 1..6 :fillin(last) # a 1 b 2 c 3
Uh, I don't think that works. First off, it would have to be:
for (@foo) Y (1..6) :fillin{ last } {...}
But I don't think that works either, since you want that last to be
associated with the for loop, which it is not lexically inside.
Honestly, I just don't think it's an option, and that :short/:long (or
:min/:max) is a better option. However, I wonder how you would get
behavior like this:
for (@foo) Y (@bar, undef xx Inf) Y (1...) :short -> $foo, $bar,
$index {...}
Hmm, probably just like that :-)
Could something like this syntax be made to work?
for (@foo ¥:fillin(undef) 1..6) but true # a but true, 1 but
true...undef but true, 6 but true
I think you've stumbled upon the reason why we made adverbs come after
operators. The important thing is the zip, not the fact that you're
filling in with undef.
Luke
Re: zip: stop when and where?
On 10/4/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > If that ends up being common, we could create a syntax for it, like > postfix:<...>: > > @array... # same as (@array, undef xx Inf) No, no, that's a bad idea, because: @array...# same as @array.elems..Inf So I think I'm pretty much with Damian on this one. I don't like the idea of it discriminating between finite and infinite lists, though. What about things like =<>, for which it is never possible to know if it is infinite? I don't think people make assumptions about the zip operator. "Does it quit on the shortest one or the longest one?" seems like a pretty common question for a learning Perler to ask. That means they'll either write a little test or look it up in the docs, and we don't need to be so strict about its failure. I'd like to go with the minimum. I was thinking a good name for the adverbs would be :long and :short. Luke
Re: zip: stop when and where?
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
I think (c) is correct, precisely for this reason. The idiom:
for 0... Y @array -> $index, $elem {...}
Is one we're trying to create. If it involves a pain like:
for 0... Y @array -> $index, $elem {
$elem // last;
}
Then it's not going to be a popular idiom.
If you want behavior (b), SWIM:
for 0... Y @array, undef xx Inf -> $index, $elem {
...
}
If that ends up being common, we could create a syntax for it, like
postfix:<...>:
@array... # same as (@array, undef xx Inf)
Luke
Re: zip: stop when and where?
Juerd wrote:
What should zip do given 1..3 and 1..6?
(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail
I'd want c, mostly because of code like
for @foo Y 0... -> $foo, $i { ... }
Pugs currently does b.
I agree that C should have named options (perhaps :min and :max) that
allow precise behaviour to be specified.
I suspect that the dwimmiest default would be for C to stop zipping at
the length of the shortest finite argument. And to fail unless all finite
arguments are of the same length. Hence:
@i3 = 1..3 ;
@a3 = 'a'..'c' ;
@i6 = 1..6 ;
zip(@a3, @i3)# 'a', 1, 'b', 2, 'c', 3
zip(@i3, @i6)# fail
zip(100..., @a3, @i3)# 100, 'a', 1, 101, 'b', 2, 102, 'c', 3
zip(100..., @a3, @i6)# fail
Damian
Re: zip: stop when and where?
I see your point. Option b does suggest that you can read ahead in a "blocked" list and get undef's. If I had to choose just one, I think I'd opt for d, but having two zip's one acting like c and one like d might be useful. Then, of course, my first thought was wrong. This one may well be, too. --- Eric <[EMAIL PROTECTED]> wrote: > Hey, > I'd just like to say that I find B a bit misleading because you > couldn't > tell that the first list ended, it could just have undef's at the > end. I > like a because it doesn't add any data that wasn't there, of course > that > could be a reason to dislike it too. On the other hand c makes a good > option > when you want to work with infinite lists. Is this something that > could be > modified on per use basis and we just choose one now as the default > "they > didn't request a specific one so use this one). > > After all that i think I agree on C specificaly because you can > provide a > good code use of it and it doesn't add any data that wasn't there > before. I > don't think it should ever lean towards (b) but them I bet someone > else will > have an equaly good use of that. ;) So in the end I think some way of > chooseing would be good, with one option picked as standard. > > -- > Eric Hodges > === Gregory Woodhouse <[EMAIL PROTECTED]> "Without the requirement of mathematical aesthetics a great many discoveries would not have been made." -- Albert Einstein
Re: zip: stop when and where?
On Tue, Oct 04, 2005 at 09:00:15PM +0200, Juerd wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
(a) and (d) are certainly wrong IMHO.
Surely zip could get a modifier to vary the behavior as desired?
for @foo ¥ 0... :greedy-> $foo, $i { ... } # (b)
for @foo ¥ 0... :conservative -> $foo, $i { ... } # (c)
Didn't we go over this a while back?
Anyway, I agree that (c) is probably the sanest default behavior.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: zip: stop when and where?
Hey, I'd just like to say that I find B a bit misleading because you couldn't tell that the first list ended, it could just have undef's at the end. I like a because it doesn't add any data that wasn't there, of course that could be a reason to dislike it too. On the other hand c makes a good option when you want to work with infinite lists. Is this something that could be modified on per use basis and we just choose one now as the default "they didn't request a specific one so use this one). After all that i think I agree on C specificaly because you can provide a good code use of it and it doesn't add any data that wasn't there before. I don't think it should ever lean towards (b) but them I bet someone else will have an equaly good use of that. ;) So in the end I think some way of chooseing would be good, with one option picked as standard. -- Eric Hodges
Re: zip: stop when and where?
That (b) certainly seems like the sensible option to me. My second
choice would be d.
A nice thing about c is that it leaves open the possibility of lazy
evaluation (zip as much of the lists as you can, leaving open the
possibility of picking up the process later). But I still prefer b.
Maybe there could be separate "lazy zip" (lzip?).
--- Juerd <[EMAIL PROTECTED]> wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
>
>
> Juerd
> --
> http://convolution.nl/maak_juerd_blij.html
> http://convolution.nl/make_juerd_happy.html
> http://convolution.nl/gajigu_juerd_n.html
>
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Without the requirement of mathematical aesthetics a great many discoveries
would not have been made."
-- Albert Einstein
Re: zip: stop when and where?
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
Yeah. This is one of those things where it is hard to have a single function
always DWYM. Algorithm::Loops solves this by just providing multiple
functions. I can't see how to solve this using MMD alone. You would need to
add an optional parameter that would specify behavior
-min (zip to the smallest list)
-undef (insert undefs as needed)
-error (blow up if the lists are not equal in size)
etc
Juerd
>
Just my 2 cents from the peanut gallery.
Cheers,
Joshua Gatcomb
a.k.a. L~R
zip: stop when and where?
What should zip do given 1..3 and 1..6?
(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail
I'd want c, mostly because of code like
for @foo Y 0... -> $foo, $i { ... }
Pugs currently does b.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: zip with ()
On Mon, Aug 01, 2005 at 01:13:52PM +0200, "TSa (Thomas Sandlaß)" wrote: : BTW, you didn't mean originally: : : say zip (@odd), (@even); # prints 13572468 or 12345678? That doesn't work, since () in list context does not enforce scalar context. It's exactly equivalent to say zip @odd, @even; which is also wrong, because zip is requires "multidimentional slice" syntax. Ordinary commas will be taken to separate items of the first slice. To separate slices requires semicolon or pipes. : Does &zip now interleave two array refs instead : of flattened arrays? No, but separating the arrays with comma doesn't work either, so Pugs currently has it wrong. The correct syntax will eventually be: zip(@odd; @even) zip @odd <== @even The parens are required only at the top statement level. Inside other bracketing structures you can omit the parens: (zip @odd; @even) just as in subscripts the semicolon separates multiple dimensions: @[EMAIL PROTECTED]; @b] Larry
Re: zip with ()
HaloO,
Luke Palmer wrote:
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
[EMAIL PROTECTED]). But of course, I could
be totally wrong. :)
I think that's right. However, it might be a good idea not to
auto-enreference such bare lists:
I don't like this notion of auto enreference/dereference at all.
Either the type system manages to dispatch things correctly or
you get an error. For the List versus Array problem this dispatch
is IMHO decideable at compile time by strictly typing @ vars as
Array and subtypes thereof. The List type to me is a Code subtype
and as such travels in & vars. I'm only unsure how easily such
variables should enter name space, that is how they behave without
sigil.
sub foo ($x) {...}
foo (1,2,3,4,5); # foo gets called with [1,2,3,4,5]
Yes, the $x makes foo an Item or even Value taker of arity 1.
The call foo (1,2,3,4,5) OTOH calls it with a List. This should
result in a type error. But sub foo (&x) might then work for a List
but not for an Item|Value call foo(1).
Since I think that * in a signature is for extending the arity of
the sub to infinity I wonder if it is possible to capture the caller's
list into a single *$arg?
sub foo (*$x) {...}
foo (1,2,3,4,5); # type of $x is now Ref of List of Int?
But with an additional array the slurpy item gets at most one value.
sub foo (*$x, [EMAIL PROTECTED]) {...}
foo (1,2,3,4,5); # $x == 1; [EMAIL PROTECTED] == 4
foo @array; # type of $x is now Ref of Array; @a is undef
When you could just as easily have said:
foo [1,2,3,4,5];
And we'll probably catch a lot of Perl 5 switchers that way. That
actually makes a lot of sense to me. The statement:
my $x = (1,2,3,4,5);
Looks like an error more than anything else.
Yep. I opt for type error "Can't assign List to Item".
By the same token I would disallow
my @a = 3; # type error "Can't assign Item to Array".
It should be
my @a = *3;
or
my @a = (3,);
Hmm, wasn't there a nullary *?
my @a = *;
say [EMAIL PROTECTED]; # prints 0
That's the "scalar
comma", which has been specified to return a list. But maybe it
should be an error.
Sorry, I don't understand this. I thought comma just is *the*
List constructor per se. Parens required to lift precedence :)
Same applies to semi-colon. (1,2,3;4,5,6) is a List of List of Int.
The main reason that we've kept a scalar comma is
for:
loop (my $x = 0, my $y = 0; $x*$y <= 16; $x++, $y++)
{...}
However, I think we can afford to hack around that. Make the first
and last arguments to loop take lists and just throw them away.
My interpretation of the loop block controler special form is that
it gets a 4-tupel (Block,Block,Block,Block). The last one is of course
the loop's body. The first is the initializer that is executed in a
scope outside the body. The second and third are the condition and
the stepper and also scoped outside the body.
Now to the comma. It should be parsed as List of Block. In your example
the argument type of loop is (List of Block,Block,List of Block,Block).
The loop instanciates an Iterator[List of Block] and uses it to
execute the Blocks one at a time. The only special case is in the
condition which evaluates only the last Block from the List of Block
for truth and the others in Void context.
Is loop supposed to be a topicalizer? Does it bind the block owner?
Does a pointy body block make sense?
loop (my $x = 0; $x < 10; $x++) -> {...} # current count in $_?
loop (my $x = 0; $x < 10; $x++){...} # $_ unchanged from outside?
loop (my $x = 0; $x < 10; $x++)
{
.blubber # what is the invocant?
}
Can the last Block also be separated with semi-colon? I guess not.
How about a Code var?
loop my $x = 0; $x < 10; $x++; say $x; # works?
loop my $x = 0; $x < 10; $x++; &foo; # works?
loop( my $x = 0; $x < 10; $x++; &foo ) # perhaps as function call?
loop
my $x = 0;
$x < 10;
$x++;
say $x; # still the loop body? Or does it need { say $x }?
loop foo; bar; blubb ->
{
say # prints return value of blubb while bar returns true
# first iteration prints return value of foo
}
Can
anyone think of any other common uses of the scalar comma?
Not me. It's a C relict.
--
$TSa.greeting := "HaloO"; # mind the echo!
Re[2]: zip with ()
LP> my $x = (1,2,3,4,5); LP> Looks like an error more than anything else. 'Perl 6 and Parrot Essentials' think different ;-) -- ___ Andrew, [EMAIL PROTECTED] ___
Re: zip with ()
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> In general, (@foo, @bar) returns a new list with the element joined,
> i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
> you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
> [EMAIL PROTECTED]). But of course, I could
> be totally wrong. :)
I think that's right. However, it might be a good idea not to
auto-enreference such bare lists:
sub foo ($x) {...}
foo (1,2,3,4,5); # foo gets called with [1,2,3,4,5]
When you could just as easily have said:
foo [1,2,3,4,5];
And we'll probably catch a lot of Perl 5 switchers that way. That
actually makes a lot of sense to me. The statement:
my $x = (1,2,3,4,5);
Looks like an error more than anything else. That's the "scalar
comma", which has been specified to return a list. But maybe it
should be an error. The main reason that we've kept a scalar comma is
for:
loop (my $x = 0, my $y = 0; $x*$y <= 16; $x++, $y++)
{...}
However, I think we can afford to hack around that. Make the first
and last arguments to loop take lists and just throw them away. Can
anyone think of any other common uses of the scalar comma?
Luke
Re: zip with ()
Hi,
TSa (Thomas Sandlaß orthogon.com> writes:
> Ingo Blechschmidt wrote:
> > say zip (@odd, @even); # &zip gets only one argument, the flattened
> > # list ( @odd, @even), containing the
>
> Why flattened? Shouldn't that be *(@odd, @even)?
IIUC:
say zip *(@odd, @even);
# &zip gets called with the parameters 1, 3, 5, 7, 2, 4, 6, 8.
say zip (@odd, @even);
# &zip gets called with one argument, (1, 3, 5, 7, 2, 4, 6, 8).
say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]);
# &zip gets called with one argument, ([1, 3, 5, 7], [2, 4, 6, 8]).
In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
[EMAIL PROTECTED]). But of course, I could
be totally wrong. :)
> > # elements (1,3,5,7,2,4,6,8). Then &zip
>
> Why not ([1,3,5,7],[2,4,6,8]) list of two array refs?
Because you'd have to explicitly take reference to them:
say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]).
(Can somebody confirm my thoughts?)
--Ingo
Re: zip with ()
HaloO, Andrew Shitov wrote: TTS> BTW, you didn't mean originally: TTS>say zip (@odd), (@even); # prints 13572468 or 12345678? That is exactly like with similar printing result of sub() call: print sqrt (16), 5; # shout print 45. That all hinges on the type of the symbol. I guess &sqrt is a unary prefix. Then print sqrt 16, 5; # should print 45 as well. The point is, to not let &sqrt 'swallow' the 5 unless it is declared listop. -- $TSa.greeting := "HaloO"; # mind the echo!
Re: zip with ()
HaloO,
Ingo Blechschmidt wrote:
Whitespace is significant:
say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even); # &zip gets two arguments, result is
# 12345678.
say zip (@odd, @even); # &zip gets only one argument, the flattened
# list (@odd, @even), containing the
Why flattened? Shouldn't that be *(@odd, @even)?
# elements (1,3,5,7,2,4,6,8). Then &zip
Why not ([1,3,5,7],[2,4,6,8]) list of two array refs?
# tries to zip this one list, resulting in
# 13572468.
If the list of two array refs is not flattened, the result should be
12345678 because how should &zip distinguish it from the other cases?
The crux of the first case not requiring parens is that &zip is declared
as listop and as such consumes the @even after the , which otherwise would
be left for &say. And if &say weren't declared/assumed listop, the @even
would be evaluated in Void context and not appear in the print at all.
Or do I miss something important? E.g. has () become a circumfix deref op?
--
$TSa.greeting := "HaloO"; # mind the echo!
Re[2]: zip with ()
TTS> BTW, you didn't mean originally: TTS>say zip (@odd), (@even); # prints 13572468 or 12345678? That is exactly like with similar printing result of sub() call: print sqrt (16), 5; # shout print 45. -- ___ Андрей, [EMAIL PROTECTED] ___
Re: zip with ()
HaloO, Andrew Shitov wrote: Is it possible to avoid significance of whitespaces? Yes, with: say zip .(@odd, @even); Looks like a method and *is* a method in my eyes. First &zip is looked-up and then bound as block owner. Arguments are of course two array refs to @odd and @even respectively. BTW, you didn't mean originally: say zip (@odd), (@even); # prints 13572468 or 12345678? Does &zip now interleave two array refs instead of flattened arrays? I think, such an aspect of Perl 6 would be awful. IB> Whitespace is significant: IB> say zip(@odd, @even); IB> say zip (@odd, @even); -- $TSa.greeting := "HaloO"; # mind the echo!
Re[2]: zip with ()
Is it possible to avoid significance of whitespaces? I think, such an aspect of Perl 6 would be awful. IB> Whitespace is significant: IB> say zip(@odd, @even); IB> say zip (@odd, @even); -- ___ Andrew, [EMAIL PROTECTED] ___
Re: zip with ()
Hi,
Andrew Shitov wrote:
> I tried zip under pugs.
>
> my @odd = (1, 3, 5, 7);
> my @even = (2, 4, 6, 8);
> my @bothA = zip @odd, @even;
> print @bothA;
>
> This code prints 12345678 as expected.
>
> After parenthesis were used to group zip arguments, results changes
> to 13572468. Is it right?
Whitespace is significant:
say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even); # &zip gets two arguments, result is
# 12345678.
say zip (@odd, @even); # &zip gets only one argument, the flattened
# list (@odd, @even), containing the
# elements (1,3,5,7,2,4,6,8). Then &zip
# tries to zip this one list, resulting in
# 13572468.
--Ingo
--
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD | understand recursion.
Athlon!|
zip with ()
Hi, I tried zip under pugs. my @odd = (1, 3, 5, 7); my @even = (2, 4, 6, 8); my @bothA = zip @odd, @even; print @bothA; This code prints 12345678 as expected. After parenthesis were used to group zip arguments, results changes to 13572468. Is it right? -- ___ Andrew, [EMAIL PROTECTED] ___
Re: zip
Goplat wrote: I have quite a few fonts, the only one I can find where | is a broken bar is "Terminal", a font for DOS programs that uses the cp437 charset, which is incompatable with latin1 (« and » are AE and AF instead of AB and BB) and it dosen't even have a ¦. So, it dosen't seem like a problem. It is still easy to confuse, but why worry? Larry's suggestion to use ¥ (JPY-sign) looks much better anyway. I think it is always important to remember that it is not only writing Perl6, but also reading Perl6 that has to be doable. Two many equivalent ways to write the same thing mean that the reader has to learn more. I think that Perl is very strong with the writing part. It is relatively easy and efficient to write in Perl, but the reading part is more of a challenge. That 1 and l look so similar is just due to the stupid convention to use fonts that make these two look very similar for source codes. But why add another problem with | and ¦ which do look similar if the resolution and size are low, if the ¥ can do the same thing in a better way? Introducing a "z" as a second alternative instead of ¥ might also cost something in terms of learning to read perl. The infix-operators that consist of letters are something that has to be learned very well in order to read perl-sources that have been written by others. So it might be good to have not too many of them. Best regards, Karl
Re: RFC 90 (v1) Builtins: zip() and unzip()
Lightning flashed, thunder crashed and "Jeremy Howard" <[EMAIL PROTECTED]> whispered: | @unzipped_list2 should not be([X,Y,Z], [A,B,C], [M]). The RFC's proposed | behaviour makes it work as the inverse of zip(), which is the desired | behaviour. The reason I used letters instead of the actual values is because I couldn't make it make any sense when it meant the length of each list. When it means the number of lists to break into, ([1,4,7], [2,5], [3,6]) makes perfect sense. -spp
Re: RFC 90 (v1) Builtins: zip() and unzip()
Stephen P. Potter wrote: > | If the list to be unzipped is not an exact multiple of the partition size, > | the final list references are not padded--their length is one less than > | the list size. For example: > | > | @list = (1..7); > | @unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5], [3,6]) > > This wording is confusing. Is $list_size or "the partition size" supposed > to be the length of each list, or the number of lists? The way it is > described leads me to think it should be the length of each list, but this > example shows it being the number of lists. I would expect the > @unzipped_list2 would return ([X,Y,Z], [A,B,C], [M]), although I can't wrap > my mind around which values should go where yet. > > It makes more sense for it to be the number of lists, in which case > @unzipped_list should be ([1,4], [2,5], [3,6]) not ([1,3,5], [2,4,6]). > You're right, Stephen, it is confusing the way I wrote it. Sorry--I'll redraft it today to try and make it more clear (and yes, I'm changing their names too!) I agree that the 2nd param would be more intuitive if it was the number of lists. I'll make that change as well. @unzipped_list2 should not be([X,Y,Z], [A,B,C], [M]). The RFC's proposed behaviour makes it work as the inverse of zip(), which is the desired behaviour.
Re: RFC 90 (v1) Builtins: zip() and unzip()
Lightning flashed, thunder crashed and Perl6 RFC Librarian <[EMAIL PROTECTED]> whispered: | =head1 TITLE | | Builtins: zip() and unzip() | [snip] | | its arguments. C would reverse this operation. | [snip] | | If the list to be unzipped is not an exact multiple of the partition size, | the final list references are not padded--their length is one less than | the list size. For example: | | @list = (1..7); | @unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5], [3,6]) This wording is confusing. Is $list_size or "the partition size" supposed to be the length of each list, or the number of lists? The way it is described leads me to think it should be the length of each list, but this example shows it being the number of lists. I would expect the @unzipped_list2 would return ([X,Y,Z], [A,B,C], [M]), although I can't wrap my mind around which values should go where yet. It makes more sense for it to be the number of lists, in which case @unzipped_list should be ([1,4], [2,5], [3,6]) not ([1,3,5], [2,4,6]). -spp
Re:MATRIX implementation [ RFC 90 (v1) Builtins: zip() and unzip()]
> "David L. Nicol" wrote: > > > > These things sound like perfectly reasonable CPAN modules. > > What's the block prevenenting their implementation w/in the > > perl5 framework? > > Jeremy and I are working on a general purpose matrix/unmatrix function > that may well be core-worthy. This would allow arbitrary reshaping of 2d > (Nd?) arrays into any form imaginable. > > However, I would probably argue that zip/unzip/merge/unmerge/whatever go > into a module (Math::Matrix?) since they'll probably just be specialized > calling forms of matrix/unmatrix. I think the trend is to put a lot of > formerly-core functions and features in modules, especially if subs get > fast enough (and it sounds like they're going to). > ]- One possible implementation of MATRICES is for example : As I read in perlguts-illustrated the array is represented as a array of POINTERS i.e. (pointer to $a[0], pto $a[1], pto $a[3], pto $a[n]) then we can have f.e. "matrix" : matrix 10x5, @a; this just reorders the list in the following LIST-ARRAY structure : (pto $a[0] .. $a[9]) --next-> (pto $a[10] .. $a[19]) ---next-> () now we have chained-arrays. The benefit : (@a is now internally known for perl as MATRIX) push @a,@b; will push one by one all elements of @b into correspondending rows in @a matrix push is now executed in MATRIX CONTEXT. If you gotcha the idea then all splice, pop,shift, unshift will do their correspodending roles. (offcource there is some glitches such as what happen if the @b array is smaller/bigger the necessary elements for the matrix - then we can have fillwith zeros, with default value ... etc) THE other operator "unmatrix" just convert the matrix back to array.. We can easly access say element 250 for example like $a[250] 'cause the exact position is is easy calculated, offcource the access will be little bit slower than normal array. WHAT HAPPEN with HASHES ?!? May be we can look at them as TABLES... = iVAN [EMAIL PROTECTED] =
Re: RFC 90 (v1) Builtins: zip() and unzip()
> "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: JH> When you've got some examples of using your proposed 'reshape' (or JH> whatever it'll be called), I'll see what the same code looks like JH> with RFC 81 notation... Cute, isn't "reshape" the name of the APL operation? Hmm, reshape is its own inverse. I'll go for that as the name of the operation. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 90 (v1) Builtins: zip() and unzip()
In message <[EMAIL PROTECTED]> "David L. Nicol" <[EMAIL PROTECTED]> wrote: > These things sound like perfectly reasonable CPAN modules. > What's the block prevenenting their implementation w/in the > perl5 framework? Nothing really. I think what people are really after is efficient implementations of these sort of primitives and so long as perl6 has support for things like fast XSUBs and iterators an efficient implementation of things like zip and reduce could probably be done as part of the standard library rather than in the core engine itself. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...Exercise caution in your daily affairs.
Re: RFC 90 (v1) Builtins: zip() and unzip()
Nathan Wiger wrote: > "David L. Nicol" wrote: > > > > These things sound like perfectly reasonable CPAN modules. > > What's the block prevenenting their implementation w/in the > > perl5 framework? > > Jeremy and I are working on a general purpose matrix/unmatrix function > that may well be core-worthy. This would allow arbitrary reshaping of 2d > (Nd?) arrays into any form imaginable. > Actually, I still remain to be convinced that RFC 81 (Lazily evaluated list generation functions) isn't already this generic tool (when used as an index to another list). When you've got some examples of using your proposed 'reshape' (or whatever it'll be called), I'll see what the same code looks like with RFC 81 notation... > However, I would probably argue that zip/unzip/merge/unmerge/whatever go > into a module (Math::Matrix?) since they'll probably just be specialized > calling forms of matrix/unmatrix. I think the trend is to put a lot of > formerly-core functions and features in modules, especially if subs get > fast enough (and it sounds like they're going to). > Definitely, if the generic foundation for them (lazily generated lists, reshape, ...) is there. But to answer Nick's question, the reason they're not in Perl 5 in this way at the moment is that Perl 5 doesn't provide the foundation required for them. Although it's easy enough to write a zip or partition function in Perl 5, because it can't be evaluated lazily and would therefore be useless for any real numeric programming. Also there's no use in having just array reshaping functions if the rest of the baggage required to avoid explicit loops isn't in the language. In general, if array notation (i.e. working with lists without explicit loops) isn't reliably efficient, I would always use explicit loops instead (since the loss of clarity is more than outweighed by the increased speed and lower memory use).
Re: RFC 90 (v1) Builtins: zip() and unzip()
"David L. Nicol" wrote: > > These things sound like perfectly reasonable CPAN modules. > What's the block prevenenting their implementation w/in the > perl5 framework? Jeremy and I are working on a general purpose matrix/unmatrix function that may well be core-worthy. This would allow arbitrary reshaping of 2d (Nd?) arrays into any form imaginable. However, I would probably argue that zip/unzip/merge/unmerge/whatever go into a module (Math::Matrix?) since they'll probably just be specialized calling forms of matrix/unmatrix. I think the trend is to put a lot of formerly-core functions and features in modules, especially if subs get fast enough (and it sounds like they're going to). -Nate
Re: RFC 90 (v1) Builtins: zip() and unzip()
David L . Nicol <[EMAIL PROTECTED]> writes: >These things sound like perfectly reasonable CPAN modules. >What's the block prevenenting their implementation w/in the >perl5 framework? No one has done it? -- Nick Ing-Simmons
Re: RFC 90 (v1) Builtins: zip() and unzip()
These things sound like perfectly reasonable CPAN modules. What's the block prevenenting their implementation w/in the perl5 framework? Ariel Scolnicov wrote: > > Damian Conway <[EMAIL PROTECTED]> writes: > > > Just to point out that the standard CS term is "merge". > > `merge' produces a list of items from 2 (or more) lists of items; > `zip' produces a list of pairs (or tuples) of items from 2 (or more) > lists of items. So in a language like Haskell which uses square > brackets for lists and round for tuples (and `==' for equality, etc.): > > merge [1,2,3,4],[5,6,7,8] == [1,5,2,6,3,7,4,8] > > and > > zip [1,2,3,4],[5,6,7,8] == [(1,5),(2,6),(3,7),(4,8)] > > (note: `merge' is often also used to denote producing a list which > respects ordering; then the above merge would produce > [1,2,3,4,5,6,7,8]). > > [...] > > It's called `zip'. Really. > > -- > Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] > Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz > 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- > Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels -- David Nicol 816.235.1187 [EMAIL PROTECTED] :wq
Re: RFC 90 (v1) Builtins: zip() and unzip()
Ariel Scolnicov wrote: > Damian Conway <[EMAIL PROTECTED]> writes: > > > Just to point out that the standard CS term is "merge". > > `merge' produces a list of items from 2 (or more) lists of items; > `zip' produces a list of pairs (or tuples) of items from 2 (or more) > lists of items. So in a language like Haskell which uses square > brackets for lists and round for tuples (and `==' for equality, etc.): > > merge [1,2,3,4],[5,6,7,8] == [1,5,2,6,3,7,4,8] > > and > > zip [1,2,3,4],[5,6,7,8] == [(1,5),(2,6),(3,7),(4,8)] > This brings up an interesting question... which behaviour would we prefer? Currently the RFC defines zip() as producing a flat list, rather than a list of references to arrays. Of course, you can always say: $haskell_zip = partition (zip @^listOfLists, scalar @^listOfLists); which is why I figured the flat-by-default version would be more useful. If we created the partitioned version by default, then the other version would be: $haskell_merge = map @^, @listOfLists; which seems a little harder to evaluate lazily (for an individual item in a tuple, that is--evaluating a whole tuple lazily would be straightforward). Assuming that the current definition remains, 'merge' does seem more appropriate (and less offensive to the 'functionally challenged' ;-)
Re: RFC 90 (v1) Builtins: zip() and unzip()
Damian Conway <[EMAIL PROTECTED]> writes: > Just to point out that the standard CS term is "merge". `merge' produces a list of items from 2 (or more) lists of items; `zip' produces a list of pairs (or tuples) of items from 2 (or more) lists of items. So in a language like Haskell which uses square brackets for lists and round for tuples (and `==' for equality, etc.): merge [1,2,3,4],[5,6,7,8] == [1,5,2,6,3,7,4,8] and zip [1,2,3,4],[5,6,7,8] == [(1,5),(2,6),(3,7),(4,8)] (note: `merge' is often also used to denote producing a list which respects ordering; then the above merge would produce [1,2,3,4,5,6,7,8]). [...] It's called `zip'. Really. -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 90 (v1) Builtins: zip() and unzip()
In message <[EMAIL PROTECTED]> Graham Barr <[EMAIL PROTECTED]> wrote: > On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote: > > > In order to reverse this operation we need an C function: > > > > @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6) > > @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6]) > > Is unzip used that often ? I wondered the same thing. As far as I can tell from a quick perusal of my copy of "Introduction to Functional Programming" there isn't a direct inverse of zip in Miranda. Of course if the array slicing RFC goes through you could always extract the original lists from a zipped list using array slices. > > =head1 IMPLEMENTATION > > > > The C and C functions should be evaluated lazily. > > lazily ? why, no other operator does by default (I am asuming here) Currently... I thought one idea for perl6 was to make more things use iterators instead of creating large temporary lists. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...I'm so close to hell I can almost see Vegas!
Re: RFC 90 (v1) Builtins: zip() and unzip()
Just to point out that the standard CS term is "merge". I guess the opposite would be..."emerge"??? Damian
Re: RFC 90 (v1) Builtins: zip() and unzip()
* Jarkko Hietaniemi ([EMAIL PROTECTED]) [14 Aug 2000 00:15]: > On Sun, Aug 13, 2000 at 06:54:10PM +1000, iain truskett wrote: > > * Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]: [...] > > > Personally, I like 'weave' rather than 'zip'. I'm happy with > > > 'unweave' too--although I'm still unsure about that one... > > > > Weave is too much like Knuth's tangle and weave pair of programs for > > his WEB idea. *sigh* All the good names are taken =) > That, however, is nowhere as well known (=confusion causing) as 'zip'. > Pretty much every English verb must have by now been taken as a name > of a piece of software, we have to draw the line somewhere... True, but we can still look. qw/fuse unite spin zigzag entwine/ etc. cheers, -- iain truskett, aka Koschei.<http://eh.org/~koschei/> Xander: But we were going to have a romantic evening! Anya: We were going to light lots of candles and have sex near them!
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Sun, Aug 13, 2000 at 06:54:10PM +1000, iain truskett wrote: > * Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]: > [...] > > Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave' > > too--although I'm still unsure about that one... > > Weave is too much like Knuth's tangle and weave pair of programs for his > WEB idea. *sigh* All the good names are taken =) That, however, is nowhere as well known (=confusion causing) as 'zip'. Pretty much every English verb must have by now been taken as a name of a piece of software, we have to draw the line somewhere... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 90 (v1) Builtins: zip() and unzip()
* Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]: [...] > Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave' > too--although I'm still unsure about that one... Weave is too much like Knuth's tangle and weave pair of programs for his WEB idea. *sigh* All the good names are taken =) > BTW, I've seen no discussion of RFC 82 (Make operators behave > consistently in a list context), so I'm not sure what to do with it... > Is that because everyone thinks it's great, or that it's stupid, or > just that no-one's got any idea what I'm trying to say? I glanced through it and thought it seemed fine. If people think something is stupid, they'll email. If people want something changed, they'll email. If something is good, they won't =) cheers, -- iain truskett, aka Koschei.<http://eh.org/~koschei/> Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. -- Anonymous.
Re: RFC 90 (v1) Builtins: zip() and unzip()
Nathan Wiger wrote: > > With zip/unzip/partition > > I really gotta say, those functions *need* to be renamed, for a variety > of reasons. First, they have well-established computer meanings > (compression, disks). Second, "partition" is too long anyways. > > I've seen numerous emails from other people saying the same thing. If > other languages name these functions zip/unzip I'd argue they're wrong. > "mop", "cleave", "weave", "mix", or any other term that doesn't already > have well-established computer meaning is acceptable. > > Jeremy, in the next version of the RFC's would you be willing to suggest > some alternatives? Yes, of course! I do read every message posted regarding the RFCs I'm maintaining, and in the 2nd version I will incorporate the suggestions that are made. Where the community hasn't reached consensus, I'll propose a solution I think is appropriate (based on the on-list debate), and include a discussion section mentioning other options--after all, in the end it's up to Larry to decide, and my view is that my role as an RFC maintainer is to summarise the combined wisdom of the Perl community to help him do that. In this case, I've got no particular feeling of ownership over the function naming I proposed--I just stole them from the names of the same functions in widely used functional languages. Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave' too--although I'm still unsure about that one... BTW, I've seen no discussion of RFC 82 (Make operators behave consistently in a list context), so I'm not sure what to do with it... Is that because everyone thinks it's great, or that it's stupid, or just that no-one's got any idea what I'm trying to say?
Re: RFC 90 (v1) Builtins: zip() and unzip()
> With zip/unzip/partition I really gotta say, those functions *need* to be renamed, for a variety of reasons. First, they have well-established computer meanings (compression, disks). Second, "partition" is too long anyways. I've seen numerous emails from other people saying the same thing. If other languages name these functions zip/unzip I'd argue they're wrong. "mop", "cleave", "weave", "mix", or any other term that doesn't already have well-established computer meaning is acceptable. Jeremy, in the next version of the RFC's would you be willing to suggest some alternatives? Alternatively, pick a different set, but I really think zip/unzip/partition are (a) confusing and (b) not obviously list manipulation functions. -Nate
Re: RFC 90 (v1) Builtins: zip() and unzip()
Jarkko Hietaniemi wrote:
> I simply can't get over the feeling that the proposed
> zip/unzip/partition functions are far too specialized/simple,
That's certainly a possibility. They are such common operations though, it
might be a win to build them in. With zip/unzip/partition and good array
slicing syntax it is possible to construct many n-dim matrix transforms and
functions.
> and that
> something more general-purpose in the order of pack/unpack (with the
> transformation spec encoded in a template) for lists would be preferable.
That's one of the things RFC 81--Lazily evaluated list generation functions,
covers. Using a generated list as the indexes to an array provides
completely flexible array transformations.
> When someone said that matrix/unmatrix would be better I did not find
> that to be a joke: on the contrary, what we are talking here would be
> a mapping from n-dim arrays to p-dim arrays. Just simply thinking in
> 1-dim lists/arrays doesn't cut it.
>
Of course. But RFCs 81, 82, 90, and 91 provide between them all the parts
required for matrix operations over any number of dimensions. Even although
the basic platform is a 1d array, n-dim operations are provided for through
generated lists, zip, unzip, and partition. For instance, let's take the
example from RFC 91 and modify it to calculate column sums from a 2d matrix:
# Add all the elements of a list together, returning the result
$sum = reduce (^total + ^element, @^elements);
# Swap the rows and columns of a list of lists
$transpose = partition(
# Find the size of each column
scalar @^list_of_lists,
# Interleave the rows
zip(@^lists_of_lists);
)
# Take a list of references to lists, and return an array of each
# sub-list's sum
$sum_cols = reduce (
push (@^total, $sum->( @^next_list )),
$transpose->(^list_of_lists),
);
# Example usage of $sum_mult
@a = (1,3,5);
@b = (2,4,6);
@c = (-1,1,-1);
@answer = @{$sum_cols->(\@a, \@b, \@c)}; #
1*2*-1,3*4*1,5*6*-1=(-2,12,-30)
Mind you, I don't think your average Perl hacker should have to worry about
all this--it would be nice if Perl also provided some easy way to use n-dim
arrays directly. However, with the building blocks I've described the n-dim
stuff could be written in pure Perl. I'm not sure that is the best way--but
it's certainly one way (and the way C++ took, when it introduced the 1d
valarray--see Stroustrup, "The C++ Programming Language, 3rd Edition",
pp662-679).
I'm still trying to work out what the alternative might look like--a set of
language constructs that operated on n-dim arrays directly. This is really
hard, but there are some good starting points in:
- PDL: pdl.perl.org
- Blitz++: http://oonumerics.org/blitz/
- POOMA: http://www.acl.lanl.gov/pooma/
PDL uses a special language ('PP') that lets the programmer explicitly
specify loops over specific dimensions. Blitz++ and POOMA are more
adventerous, providing advanced iterator/index classes that operate over
n-dim arrays in defined ways, but require much more work from the compiler.
Of course, if we go down this route, we would need to ensure that related
RFCs (like 'reduce') can handle using these kinds of arrays and iterators.
Re: RFC 90 (v1) Builtins: zip() and unzip()
I simply can't get over the feeling that the proposed zip/unzip/partition functions are far too specialized/simple, and that something more general-purpose in the order of pack/unpack (with the transformation spec encoded in a template) for lists would be preferable. When someone said that matrix/unmatrix would be better I did not find that to be a joke: on the contrary, what we are talking here would be a mapping from n-dim arrays to p-dim arrays. Just simply thinking in 1-dim lists/arrays doesn't cut it. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 90 (v1) Builtins: zip() and unzip()
what about (not zip() offcource :")): @a = (1,2,3); @b = (4,5,6); @c = (7,8,9); zip (how,@a,@b,@c); i.e. @list = zip (0,@a,@b,@c); #stright result (1,2,3,4,5,6,7,8,9) @list = zip (1,@a,@b,@c); #reverse result (7,8,9,5,6,7,1,2,3) @list = zip(2,@a,@b,@c); # all first elems, then all second..etc result (1,4,7,2,5,8,3,6,9) @list = zip(3,@a,@b,@c); #and reverse... result (7,4,1,8,5,2,9,6,3) Also we can tell : @list = zip(1,@a,@b,reverse @c); = iVAN [EMAIL PROTECTED] =
Re: RFC 90 (v1) Builtins: zip() and unzip()
Subject: RFC 90 (v1) Builtins: zip() and unzip() I just don't like the name zip(), unzip() - shold be saved for something that will really do commpression. Variants : combine I like merge too.. As of this it will be good if there some sort of compression internally by the perl, say for the data structures... I'm not sure how easly this can be done, but this will big win especialy when worknig on big text files or arrays (RLE is enought in most cases). everyone knows the BLOATED https's under mod_perl. For example Interbase DB uses RLE compression for at record level... this is big saving ... = iVAN [EMAIL PROTECTED] =
Re: RFC 90 (v1) Builtins: zip() and unzip()
Dave Storrs <[EMAIL PROTECTED]> writes: > On Fri, 11 Aug 2000, Damien Neil wrote: > > > On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > > > I think I like plow() or maybe just weave() > > > > weave() and ravel()? > > > > - Damien [...] > The word "ravel" is generally not used, either...you generally see > "unravel." > > Maybe weave() and unweave(), to emphasize that they are go > together? Unfortunately `weave' is already a program, too (Knuth's WEB uses `tangle' and `weave' (not as antonyms)). The advantage of `zip' is that that is the name of the operation being performed. -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 90 (v1) Builtins: zip() and unzip()
Philip Newton wrote: > Would it not be more natural to pass the *number* of lists to unzip, > rather than the desired length? This way, unzip() would know to pick off > elements two-at-a-time, three-at-a-time, etc., rather than having to go > through the zipped list, count the elements, divide by $list_size, etc. > Could be. It's a bit more intuitive too, isn't it? (The 2nd param is the 'step size'). > Unless I misunderstood the example and you wanted the result to be > ([1,2,3], [4,5,6]) in which case unzip would not have to do nearly as much > work. But then (1..7) would unzip(3) into ([1,2,3], [4,5,6], [7]). No, you didn't misunderstand. That's partition(), which is RFC 91.
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Sat, Aug 12, 2000 at 07:22:01AM +1000, Damian Conway wrote: > dwim @results, dwim $stuff, @args, %hey; > > Can you say 'Lisp'? Lithp Michael (who couldn't resist) -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 90 (v1) Builtins: zip() and unzip()
> In fact, perl really only needs one OP: > >@results = dwim $stuff, @args, %hey; > > (Well, I guess that's two: the assignment is an op also.) dwim @results, dwim $stuff, @args, %hey; Can you say 'Lisp'? Damian
Re: RFC 90 (v1) Builtins: zip() and unzip()
At 04:36 PM 8/11/00 -0400, John Porter wrote: >Damian Conway wrote: > >> Note that cleave is its own antonym! :-) > > > > I can see it now: > > > > @interspersed = cleave(@list1, @list2, @list3) > > @separated= cleave(3,@interspersed); > > > > Now *that's* DWIM! ;-) > >In fact, perl really only needs one OP: > > @results = dwim $stuff, @args, %hey; > >(Well, I guess that's two: the assignment is an op also.) Nah, toss the assignment op and replace it with dwim too. Perl will just do all possible operations simultaneously (in constant time, of course) and the right result will collapse out the other end. Yeah, that's the ticket... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 90 (v1) Builtins: zip() and unzip()
> Note that cleave is its own antonym! :-) I can see it now: @interspersed = cleave(@list1, @list2, @list3) @separated= cleave(3,@interspersed); Now *that's* DWIM! ;-) Damian
Re: RFC 90 (v1) Builtins: zip() and unzip()
Damian Conway wrote: >> Note that cleave is its own antonym! :-) > > I can see it now: > > @interspersed = cleave(@list1, @list2, @list3) > @separated= cleave(3,@interspersed); > > Now *that's* DWIM! ;-) In fact, perl really only needs one OP: @results = dwim $stuff, @args, %hey; (Well, I guess that's two: the assignment is an op also.) -- John Porter
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, 11 Aug 2000, Damien Neil wrote: > On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > > I think I like plow() or maybe just weave() > > weave() and ravel()? > > - Damien > Unfortunately, ravel has two opposite meanings (according to www.m-w.com): 1 a : to separate or undo the texture of : UNRAVEL b :to undo the intricacies of : DISENTANGLE 2 : ENTANGLE, CONFUSE The word "ravel" is generally not used, either...you generally see "unravel." Maybe weave() and unweave(), to emphasize that they are go together? Dave
RE: RFC 90 (v1) Builtins: zip() and unzip()
Graham Barr:
> I know other languages call it zip, but personally I dislike that
name
> as zip() is commonly used with reference to compression. Although
> I do not have a good alternative.
Personally, I'd like join() to do this:
@a = (1,3,5) ;
@b = (2,4,6) ;
@list = join(@a, @b) ; # (1,2,3,4,5,6)
Likewise split could do this:
(@a, @b) = split (2, @list) ; # @a = (1,3,5), @b = (2,4,7)
Although this is ambiguous, because this also looks right:
@list = ('a','b','c','d','e','f') ;
(@a, @b) = split ('d', @list) ; # @a = ('a','b','c'), @b = ('e','f')
# looks like
the analog to splitting a scalar...
... although, perhaps the proposed want() could be used to tell
split how many arrays it's shoving
things in to, in which case the first version would:
(@a, @b) = split (2, @list) ; # @a = (1) , @b = (3,4,5,6)
and
(@a, @b) = split (@list) ; # @a = (1,3,5), @b = (2, 4, 7)
I'm probably, once again, in the minority as far as taste for
terminology goes. :)
Dirk Myers
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > I think I like plow() or maybe just weave() weave() and ravel()? - Damien
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, 11 Aug 2000, Brad Hughes wrote: > Andy Wardley wrote: > > > fold() and unfold()? > > > > merge() and cleave()? > > collate() and ...? > Sure, and if it throws an exception you get a papercut().
Re: RFC 90 (v1) Builtins: zip() and unzip()
Andy Wardley wrote: > > > I know other languages call it zip, but personally I dislike that name > > as zip() is commonly used with reference to compression. Although > > I do not have a good alternative. > > fold() and unfold()? > > merge() and cleave()? > > A collate() and ...?
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 06:25:07PM +0100, Andy Wardley wrote: > > I know other languages call it zip, but personally I dislike that name > > as zip() is commonly used with reference to compression. Although > > I do not have a good alternative. > > fold() and unfold()? People would confude that for fold() in other languages which is like reduce() > merge() and cleave()? I think I like interleave() best, but it's too long. thesaurus.com returns [Verbs] lie between, come between, get between; intervene, slide in, interpenetrate, permeate. put between, introduce, import, throw in, wedge in, edge in, jam in, worm in, foist in, run in, plow in, work in; interpose, interject, intercalate, interpolate, interline, interleave, intersperse, interweave, interlard, interdigitate; let in, dovetail, splice, mortise; insinuate, smuggle; infiltrate, ingrain. interfere, put in an oar, thrust one's nose in; intrude, obtrude; have a finger in the pie; introduce the thin end of the wedge; thrust in (insert) [more]. I think I like plow() or maybe just weave() Graham.
Re: RFC 90 (v1) Builtins: zip() and unzip()
Andy Wardley wrote: > cleave()? Note that cleave is its own antonym! :-) -- John Porter
Re: RFC 90 (v1) Builtins: zip() and unzip()
> Builtins: zip() and unzip() Think of some other names, please. -- John Porter
Re: RFC 90 (v1) Builtins: zip() and unzip()
On 11 Aug 2000, Perl6 RFC Librarian wrote: > its arguments. C would reverse this operation. [...] > In order to reverse this operation we need an C function: > > @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6) > @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6]) Would it not be more natural to pass the *number* of lists to unzip, rather than the desired length? This way, unzip() would know to pick off elements two-at-a-time, three-at-a-time, etc., rather than having to go through the zipped list, count the elements, divide by $list_size, etc. Unless I misunderstood the example and you wanted the result to be ([1,2,3], [4,5,6]) in which case unzip would not have to do nearly as much work. But then (1..7) would unzip(3) into ([1,2,3], [4,5,6], [7]). Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 90 (v1) Builtins: zip() and unzip()
> I know other languages call it zip, but personally I dislike that name > as zip() is commonly used with reference to compression. Although > I do not have a good alternative. fold() and unfold()? merge() and cleave()? A
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 10:06:38AM -0700, Nathan Wiger wrote: > > I know other languages call it zip, but personally I dislike > > that name as zip() is commonly used with reference to compression. > > Ditto, I really dislike zip() and unzip(). They're PC and even UNIX > commands on several platforms now, increasing confusion. > > Here's two names: mix() and unmix(). It's what's happening, right? Just > as short too. mix() sounds awfully disorderly. interleave()? > > No need for the \ other builtin operators like shift,pop,splice > > etc dont need them, zip should not either. splice() would be fine, but... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 90 (v1) Builtins: zip() and unzip()
> I know other languages call it zip, but personally I dislike > that name as zip() is commonly used with reference to compression. Ditto, I really dislike zip() and unzip(). They're PC and even UNIX commands on several platforms now, increasing confusion. Here's two names: mix() and unmix(). It's what's happening, right? Just as short too. > No need for the \ other builtin operators like shift,pop,splice > etc dont need them, zip should not either. Agreed. -Nate
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote:
>
> =head1 ABSTRACT
>
> It is proposed that two new functions, C, and C, be added to
> Perl. C would return a list that interleaved
> its arguments. C would reverse this operation.
I know other languages call it zip, but personally I dislike that name
as zip() is commonly used with reference to compression. Although
I do not have a good alternative.
> @a = (1,3,5);
> @b = (2,4,6);
> @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
No need for the \ other builtin operators like shift,pop,splice etc dont
need them, zip should not either. It's prototype would be (\@\@;\@\@\@\@\@\@)
> In order to reverse this operation we need an C function:
>
> @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
> @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6])
Is unzip used that often ?
> =head1 IMPLEMENTATION
>
> The C and C functions should be evaluated lazily.
lazily ? why, no other operator does by default (I am asuming here)
> Effectively, C creates an iterator over multiple lists. If used as
> part of a reduction, the actual interleaved list need never be created.
Yes it should return an iterator in an iterator context.
An example I would use is
for my($a,$b) (zip(@a,@b)) {
# code
}
which would loop through both array together.
Graham.
RFC 90 (v1) Builtins: zip() and unzip()
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins: zip() and unzip()
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 11 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 90
=head1 ABSTRACT
It is proposed that two new functions, C, and C, be added to
Perl. C would return a list that interleaved
its arguments. C would reverse this operation.
=head1 DESCRIPTION
Miranda, the upcoming Python v2.0, and numerous functional languages use
a function called C to interleave the arguments of arrays together.
It is proposed that Perl implement this function, and evaluate it lazily.
For instance:
@a = (1,3,5);
@b = (2,4,6);
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
This makes it easy to operate on multiple lists using flexible reduction
functions:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
print $sum_xy->(\@a, \@b); # Prints '44', i.e. 1*2+3*4+5*6
In order to reverse this operation we need an C function:
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
@unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6])
If the list to be unzipped is not an exact multiple of the partition size,
the final list references are not padded--their length is one less than
the list size. For example:
@list = (1..7);
@unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5], [3,6])
=head1 IMPLEMENTATION
The C and C functions should be evaluated lazily.
Effectively, C creates an iterator over multiple lists. If used as
part of a reduction, the actual interleaved list need never be created.
For instance:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
$answer = $sum_xy->(\@a, \@b);
should be evaluated as if it read:
$answer = 0;
$answer += $a[$_] * $b[$_] for (0..$#a-1));
which does not need to create an intermediate list.
=head1 REFERENCES
RFC 23: Higher order functions
RFC 76: Builtin: reduce
