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 proble
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
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 a
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 @
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 (@od
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 symb
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 *
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 PROTECTE
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 PROTE
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 equiva
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);
--
___
Andre
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; # sho
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]
___
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.h
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 . . .
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])
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... -
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
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 optio
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
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.
--
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
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... ->
ay.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 assumpt
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
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
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 = (&
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 whethe
t 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 leng
ikely 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 zippin
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
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
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
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.
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
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)]
Anywa
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
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 ->
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. Th
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])
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 ob
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 do
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
-concurrency.pod
Log Message:
---
spec zip-latest
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
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 language
> 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:
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 UNI
> 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
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]
> Builtins: zip() and unzip()
Think of some other names, please.
--
John Porter
Andy Wardley wrote:
> cleave()?
Note that cleave is its own antonym! :-)
--
John Porter
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()?
P
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 ...?
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().
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
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:
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.c
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 $stu
> 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
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
> 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
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
--
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
- 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 (Knu
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, sa
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, the
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 m
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/partitio
> 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 say
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&
* 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 p
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 un
* 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 h
Just to point out that the standard CS term is "merge".
I guess the opposite would be..."emerge"???
Damian
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);
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 lan
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 it
t;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 (an
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
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
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
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
> "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 i
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,
ts. 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.
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
ction
> 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
>
-operators.pod
Log Message:
---
[S03] Fix ttiars in Zip operators
:
M S17-concurrency.pod
Log Message:
---
Add examples for Supply.(merge|zip)
:
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
:
M S17-concurrency.pod
Log Message:
---
Supply.(zip|merge) can be called as class method
92 matches
Mail list logo
