[perl #133017] First intermediate value of reduction with zip operator
Some extra info: Output on all releases (not a regression because the output was always wrong): https://gist.github.com/b4b27b8088a230a6051d634dc7b2d13e The change in behavior happened in (2017-03-21) https://github.com/rakudo/rakudo/commit/16f950b30572e0fa584ddfab1e84e5ef0ca5dfc9 Which links to RT#131009 ( https://rt.perl.org/Ticket/Display.html?id=131009 ) Also, FYI, we also accept bug reports on github: https://github.com/rakudo/rakudo/issues On 2018-03-23 07:16:22, wellnho...@aevum.de wrote: > When using a reduction operator with the "intermediate results" option > combined with a zip operator, e.g. [\Z+], the first intermediate value > is wrong: > > say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300); > # got: ((6) (11 22 33) (111 222 333)) > # expected: ((1 2 3) (11 22 33) (111 222 333)) > > Reduction with hyper operators like [\<<+>>] seems to work. > > Only tested online on tio.run > > Rakudo version 2017.12 built on MoarVM version 2017.12 > implementing Perl 6.c. > > and code-golf.io: > > Rakudo version 2018.03 built on MoarVM version 2018.03 > implementing Perl 6.c > > Nick
[perl #133017] First intermediate value of reduction with zip operator
# New Ticket Created by Nick Wellnhofer # Please include the string: [perl #133017] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=133017 > When using a reduction operator with the "intermediate results" option combined with a zip operator, e.g. [\Z+], the first intermediate value is wrong: say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300); # got: ((6) (11 22 33) (111 222 333)) # expected: ((1 2 3) (11 22 33) (111 222 333)) Reduction with hyper operators like [\<<+>>] seems to work. Only tested online on tio.run Rakudo version 2017.12 built on MoarVM version 2017.12 implementing Perl 6.c. and code-golf.io: Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c Nick
Re: zip mystery
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:29 PM
To: perl6-users <perl6-us...@perl.org>
Subject: Re: zip mystery
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:19 PM
To: perl6-users <perl6-us...@perl.org>
Subject: zip mystery
Hi All,
This runs:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/BlankFile.txt", :out);
And this also works (bash)
zip -j eraseme.zip /opt/xxx/yyy/zzz/diags/*
But this does not:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/*", :out);
warning: name not matched: /opt/xxx/yyy/zzz/diags/*
What am I doing wrong?
Many thanks,
-T
On 07/17/2017 05:22 PM, Mark Devine wrote:
T,
What happens when you do this?
my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile, $DiagDir ~
'/*', :out);
Mark
with $DiagDir ~ '/*'
warning: name not matched: /opt/Cimcor/CimTrak/CimTrakServer/diags/*
On 07/17/2017 05:33 PM, Mark Devine wrote:
> T,
>
> It appears to be a 'zip' error, not a Perl 6 issue. Perhaps use 'zip
-r' (explicit recursion) instead of '/*' (implicit "glob").
>
> Mark
>
>
Hi Mark,
-jr did the trick!
I had avoided trying it as I thought it would throw an error
as two of the requested entities were files and not
directories. But the zip folks had already thought of
that and it worked perfectly.
Thank you!
-T
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
Re: zip mystery
On Mon, Jul 17, 2017 at 8:18 PM, ToddAndMargo <toddandma...@zoho.com
<mailto:toddandma...@zoho.com>> wrote:
But this does not:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/*", :out);
warning: name not matched: /opt/xxx/yyy/zzz/diags/*
What am I doing wrong?
On 07/17/2017 05:45 PM, Brandon Allbery wrote:
run() does not use a shell. The shell is what understands that * and
expands it to a list of matching files. If you want that expansion, use
shell() or use Perl 6 to get the directory contents separately and send
it along as a list (see https://docs.perl6.org/type/IO::Path#routine_dir).
Now I understand. Thank you!
Re: zip mystery
On Mon, Jul 17, 2017 at 8:18 PM, ToddAndMargo <toddandma...@zoho.com> wrote:
> But this does not:
>
> my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
> "$DiagDir/*", :out);
>
> warning: name not matched: /opt/xxx/yyy/zzz/diags/*
>
> What am I doing wrong?
>
run() does not use a shell. The shell is what understands that * and
expands it to a list of matching files. If you want that expansion, use
shell() or use Perl 6 to get the directory contents separately and send it
along as a list (see https://docs.perl6.org/type/IO::Path#routine_dir).
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
RE: zip mystery
T,
What happens when you do this?
my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile, $DiagDir ~ '/*', :out);
Mark
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:19 PM
To: perl6-users <perl6-us...@perl.org>
Subject: zip mystery
Hi All,
This runs:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/BlankFile.txt", :out);
And this also works (bash)
zip -j eraseme.zip /opt/xxx/yyy/zzz/diags/*
But this does not:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/*", :out);
warning: name not matched: /opt/xxx/yyy/zzz/diags/*
What am I doing wrong?
Many thanks,
-T
Re: zip mystery
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:19 PM
To: perl6-users <perl6-us...@perl.org>
Subject: zip mystery
Hi All,
This runs:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/BlankFile.txt", :out);
And this also works (bash)
zip -j eraseme.zip /opt/xxx/yyy/zzz/diags/*
But this does not:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/*", :out);
warning: name not matched: /opt/xxx/yyy/zzz/diags/*
What am I doing wrong?
Many thanks,
-T
On 07/17/2017 05:22 PM, Mark Devine wrote:
T,
What happens when you do this?
my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile, $DiagDir ~ '/*', :out);
Mark
with $DiagDir ~ '/*'
warning: name not matched: /opt/Cimcor/CimTrak/CimTrakServer/diags/*
zip mystery
Hi All,
This runs:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/BlankFile.txt", :out);
And this also works (bash)
zip -j eraseme.zip /opt/xxx/yyy/zzz/diags/*
But this does not:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/*", :out);
warning: name not matched: /opt/xxx/yyy/zzz/diags/*
What am I doing wrong?
Many thanks,
-T
[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 <sterl...@hanenkamp.com> 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 <n...@detonation.org> 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
[perl #122230] Zip operator doesn't extend lists ending in a Whatever
For the records: TimToady++ today explained the underlying problem (final *
NYI):
bartolin I've got a question about zip: S03 says By default the zip
function reads to the end of the shortest list, but a short list may always be
extended arbitrarily by putting * after the final value, which
replicates the final value as many times as necessary.
bartolin what is the expected result of '(1, 2, *) Z (1, 2, 3, *)'? is it
'(1, 1), (2, 2), (2, 3)' or rather an infinite list '(1, 1), (2, 2), (2, 3),
(2, 3), ...'?
bartolin some tests in S03-metaops/zip.t seem to suggest the latter.
TimToady bartolin: final * is not implemented
bartolin TimToady: yes, but I'm trying to implement it ;-)
TimToady well, 1,2,* should be 1, 2 xx *
TimToady but the tricky bit is implementing @list, *
TimToady you can't just assume you have the value to xx at compile time
bartolin I see. it's probably above my skills, but I was curios anyway ;-)
TimToady it's probably not worth thinking about until after the GLR
TimToady and it might be the wrong notation anyway
TimToady plus, you can always say @array, {$_} ... * currently
TimToady m: say 1,2,3, {$_} ... *
+camelia rakudo-moar 4d2710: OUTPUT«1 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
3 3 3 3 3 3 3 3 3 ...»
TimToady maybe it should just be a method: (1,2,3).extend
TimToady or some such
bartolin ok, thanks for explaining! I think I'll leave it as it is ;-)
[perl #122849] A * as last element does not extend list for infix:Z (zip)
There was already a ticket for this problem (#122230). Also the test in question was a duplicate of a test in S03-metaops/zip.t -- which is handled in ticket #122230. I removed the redundant test from S03-operators/misc.t and I'm closing this ticket.
[perl #122849] A * as last element does not extend list for infix:Z (zip)
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #122849]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=122849
There is a fuged test in S03-operators/misc.t that tests, whether a * as the
last element of a list extends this list for infix:Z operator:
# LS03/Traversing arrays in parallel/but a short list may always be extended
arbitrarily
#?rakudo todo nom regression
#?niecza todo
{
is (1, 2, * Z a b c d).join('|'),
'1|a|2|b|2|c|2|d',
'A * as the last value extends lists for infix:Z (zip)';
}
This does currently not work:
1, 2, * Z a b c d
1 a 2 b * c
[perl #122230] Zip operator doesn't extend lists ending in a Whatever
# New Ticket Created by Will Coleda # Please include the string: [perl #122230] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=122230 Several tests in t/spec/S03-metaops/zip.t were marked as nom regression and either fail or explode. See file for tests marked with this ticket number. -- Will Coke Coleda
[perl #122230] Zip operator doesn't extend lists ending in a Whatever
On Fri Jul 04 19:54:26 2014, coke wrote: Several tests in t/spec/S03-metaops/zip.t were marked as nom regression and either fail or explode. See file for tests marked with this ticket number. Also see S03-metaops/hyper.t -- Will Coke Coleda
[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 timona...@perpetuum-immobile.de 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 l...@dijkmat.nl 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 l...@dijkmat.nl Date: 2014-04-19 (Sat, 19 Apr 2014) Changed paths: M S17-concurrency.pod Log Message: --- Add examples for Supply.(merge|zip)
[perl #119337] [BUG] timeout when just doing 'zip' in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #119337] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=119337 jnthn r: zip camelia rakudo d9f8d6: OUTPUT«(timeout)» * masak submits rakudobug on jnthn's timeout * jnthn wonders where zip is defined jnthn oh... jnthn my zip := infix:Z; jnthn :) masak jnthn: still shouldn't hang. jnthn masak: aye, no idea why it does that.
[perl #75818] [BUG] [PATCH] Zip operator Z should return a list of parcels
On Thu Jun 17 00:38:17 2010, ciphertext wrote: ciphertext: rakudo: (1,2,3 Z 4,5,6).perl.say p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)» ciphertext: rakudo: (1,2,3 Z[,] 4,5,6).perl.say p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)» pmichaud: (1,2,3 Z[,] 4,5,6).perl.say pmichaud: ((1, 4), (2, 5), (3, 6)) pmichaud: (in the new branch) ciphertext: pmichaud: that's what i'm getting, but the spec says that Z should be an alias for Z[,] ciphertext: The Z, operator is perhaps more clearly written as Z[,]. However, this list form is common enough to have a shortcut, the ordinary infix Z operator described earlier. pmichaud: sounds like a rakudo bug to me then. Also from S03: 1,2 Z 3,4 # (1,3),(2,4) This appears to be working now: 08:45 [Coke] rakudo: (1,2,3 Z[,] 4,5,6).perl.say 08:45 +p6eval rakudo 7408d6: OUTPUT«((1, 4), (2, 5), (3, 6)).list» 08:45 [Coke] rakudo: (1,2,3 Z, 4,5,6).perl.say 08:45 +p6eval rakudo 7408d6: OUTPUT«((1, 4), (2, 5), (3, 6)).list» There's a test in S03-metaops/zip.t to make sure this parses, but not to make sure it works. -- Will Coke Coleda
[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 tadzi...@gmail.com Date: 2011-06-11 (Sat, 11 Jun 2011) Changed paths: M S03-operators.pod Log Message: --- [S03] Fix ttiars in Zip operators
[perl #75818] [BUG] [PATCH] Zip operator Z should return a list of parcels
# New Ticket Created by J S # Please include the string: [perl #75818] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75818 ciphertext: rakudo: (1,2,3 Z 4,5,6).perl.say p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)» ciphertext: rakudo: (1,2,3 Z[,] 4,5,6).perl.say p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)» pmichaud: (1,2,3 Z[,] 4,5,6).perl.say pmichaud: ((1, 4), (2, 5), (3, 6)) pmichaud: (in the new branch) ciphertext: pmichaud: that's what i'm getting, but the spec says that Z should be an alias for Z[,] ciphertext: The Z, operator is perhaps more clearly written as Z[,]. However, this list form is common enough to have a shortcut, the ordinary infix Z operator described earlier. pmichaud: sounds like a rakudo bug to me then. Also from S03: 1,2 Z 3,4 # (1,3),(2,4) zip.patch Description: Binary data
[perl #73816] Zip flattens result
# New Ticket Created by Mark J. Reed # Please include the string: [perl #73816] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=73816 my @a = (1,2) Z (3,4); say @a.perl [1, 3, 2, 4] Per S03, that should be [[1,3],[2,4]]. Tried to write a test case for this, but that attempt was complicated by the fact that this test: is [[1,2],[3,4]], [1,2,3,4] currently passes. Opening a separate bug for that. -- Mark J. Reed markjr...@gmail.com
Zip overflattens
Rakudo HEAD as of fed46878c492186a006c7a5a8500befda962714c: a b X (1,2) - [['a',1],['a',2],['b',1],['b',2]] a b Z (1,2) - ['a', 1, 'b', 2] Per S03, the second one should yield [['a',1],['b',2]]. I'd expect the two ops to flatten the same amount, regardless. Also, the above is a manual Perlification of the results; calling .perl on either gives the LTA result GatherIterator.new(). -- Mark J. Reed markjr...@gmail.com
[perl #64474] Whatever do not work as specified with zip operator
# New Ticket Created by Ilya Belikin # Please include the string: [perl #64474] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=64474 Hi there, say (a b c Z [1,*]).perl [a, 1, b, *] # wrong, should be: [a, 1, b, *, c, *] S03, L4346: By default the Czip function reads to the end of the shortest list, but a short list may always be extended arbitrarily by putting C* after the final value, which replicates the final value as many times as necessary. Thank you! Ilya
[perl #60898] Zip and ranges don't mix
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #60898] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60898 10:04 moritz_ rakudo: say (a b c Z 1..10).perl 10:05 p6eval rakudo 33300: OUTPUT[elements() not implemented in class 'Range'#current instr.: 'infix:Z' pc 4039 (src/gen_builtins.pir:2555)#] 10:05 moritz_ rakudo: say (a b c Z list(1..10)).perl 10:05 p6eval rakudo 33300: OUTPUT[[a, 1, b, 2, c, 3]#] So infix:Z doesn't seem to like Range objects (sorry, the copy paste substituted the newline character with #, I'm on an UTF-8 deprived terminal rights now :-/ )
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
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 . . .
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?
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
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: 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 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 Cexists function be used for that (if exists $b {...})?
Dave.
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?
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 Cexists 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 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
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 { term op term adverb? }
Where adverb 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 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...
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 = 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('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 a 1 b 2 c 3; 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?
Damian Conway skribis 2005-10-05 10:05 (+1000): I suspect that the dwimmiest default would be for Czip 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?
I guess nobody mentioned this, so I don't know how people on perl-language feel about 'do it the same was as language', 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 Czip 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?
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 Czip 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 Czip works like this:
Czip interleaves elements from each of its arguments until
any argument is (a) exhausted of elements Iand (b) doesn't have
a Cfill property.
Once Czip stops zipping, if any other element has a known finite
number of unexhausted elements remaining, the zip 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?
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on Czip 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?
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 Czip.
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 10/5/05, Damian Conway [EMAIL PROTECTED] wrote: So I now propose that Czip works like this: Czip interleaves elements from each of its arguments until any argument is (a) exhausted of elements Iand (b) doesn't have a Cfill property. Once Czip stops zipping, if any other element has a known finite number of unexhausted elements remaining, the zip 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?
Luke wrote:
Once Czip stops zipping, if any other element has a known finite
number of unexhausted elements remaining, the zip 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?
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 Czip should have named options (perhaps :min and :max) that
allow precise behaviour to be specified.
I suspect that the dwimmiest default would be for Czip 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?
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?
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
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: 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
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?
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?
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?
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 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: 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 ()
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!|
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 ()
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 ()
TTS BTW, you didn't mean originally: TTSsay 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, 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: zip with ()
HaloO, Andrew Shitov wrote: TTS BTW, you didn't mean originally: TTSsay 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 ()
Hi, TSa (Thomas Sandlaß Thomas.Sandlass at 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 ()
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[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] ___
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
On Tue, Mar 15, 2005 at 02:47:33AM -0600, Rod Adams wrote:
: I'm trying to define zip(), but can't come up with a signature for a
: function that returns a lazy list of lvalues, but the list itself is not
: lazy?
If we go with my once-upon-a-time notion of using zip(@a;@b), then it
naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED]
: As a second matter, can you declare a type for the elements of a slurpy
: array?
Yes, and it distributes as any array return type declaration would.
: So far I have:
:
: multi sub zip (Array [EMAIL PROTECTED]) returns List {
: gather {
: while any(@lists) {
any() is not guaranteed to produce left-to-right order.
: for @lists - @list {
: take shift @list;
: }
: }
: }
: }
:
: But I can't tackle the lvalue problem.
Why do they need to be lvalues? I always thought of zip as non-destructive.
Has zip historically been destructive in other languages?
: btw, I'm defining the semantics of some of several functions by simply
: supplying a reference implementation.
That's cool.
Larry
Re: zip
Larry Wall wrote:
If we go with my once-upon-a-time notion of using zip(@a;@b), then it
naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED]
It pretty much has to use the list of lists syntax, since the number of
Arrays we are zipping is variadic, and that means using a slurpy, which
would flatten the arrays into one. So the semicolons stay. Unless
there's a non-flattening slurpy syntax out there
: As a second matter, can you declare a type for the elements of a slurpy
: array?
Yes, and it distributes as any array return type declaration would.
Does this mean that we can define multiple slurpuy arrays (and
hashes?!?) in a parameter list, of different types, and Perl will sort
the arguments into the right slurpy for us? If so, how does this
interact with the answer about C@CALLER::_?
: So far I have:
:
: multi sub zip (Array [EMAIL PROTECTED]) returns List {
: gather {
: while any(@lists) {
any() is not guaranteed to produce left-to-right order.
I'm not counting on it being ordered. I'm testing to see if any of the
lists still has anything left in it. The left to right-ness of the
processing is done in the Cfor.
: for @lists - @list {
: take shift @list;
: }
: }
: }
: }
:
: But I can't tackle the lvalue problem.
Why do they need to be lvalues? I always thought of zip as non-destructive.
Has zip historically been destructive in other languages?
I wasn't aware of a Czip in other languages.
My thought was that people might want to update the values stored
inside, as an homage to my common Perl 5 construct:
for ($var1, $var2) {
s/.../.../;
s/.../.../;
}
(and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to:
for $var1, $var2 - $_ is rw {
s/.../.../;
s/.../.../;
}
though
given $var1 {
s/.../.../;
s/.../.../;
}
is nice.
)
But if you don't see the need for lvalueing the elements coming out of
Czip, that certainly makes things easier. :-)
-- Rod Adams
Re: zip
Larry Wall wrote:
Well paint yourself unchagrined, because S04 sez:
Parameters are by default constant within the block. You can
declare a parameter read/write by including the is rw trait. If
you rely on $_ as the implicit parameter to a block, then then $_
is considered read/write by default. That is, the construct:
for @foo {...}
is actually short for:
for @foo - $_ is rw {...}
so you can modify the current list element in that case. However,
any time you specify the arguments, they default to read only.
gets out unchagrining paint and splashes it about. :-)
You know, the amazing thing about those Synopses and Apocalypses you
wrote is that no matter how many times I read them, I always find 5 new
things in them on each pass. And I'm the kind of guy who typically
absorbs entire 200 page reference manuals in one pass. I swear you found
the English equivalent of Quantum Mechanics in there, where entire
paragraphs exist and don't exist at the same time, without changing. :-)
Of course, I now have to question the need for Cgiven. Other than
linguistics, which is not to be dismissed, what difference is there between
given $expr { ... }
and
for $expr { ... }
with equivalent ...'s?
hmm. Come to think of it, the Cfor would flatten $expr if it happened
to look like an array or something equally bumpy, where Cgiven would
not. But perhaps it would make sense to define Cfor and Cgiven as
synonyms in all other ways but autoflatten.
As far as linguistics go, for makes a suitable replacement for given
in my head. It's just a very heavily loaded term when you leave English
and enter CS-speak.
-- Rod Adams
Re: zip
Larry Wall skribis 2005-03-16 12:17 (-0800):
for @foo {...}
is actually short for:
for @foo - $_ is rw {...}
Has there been any decision on - yet? If - is there, it's much
easier to say that without arguments, - $_ is used. That way, there is
no surprising magic is rw, but just another operator (that happens to
be the exact same thing in practice).
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
zip
I'm trying to define zip(), but can't come up with a signature for a
function that returns a lazy list of lvalues, but the list itself is not
lazy?
As a second matter, can you declare a type for the elements of a slurpy
array?
So far I have:
multi sub zip (Array [EMAIL PROTECTED]) returns List {
gather {
while any(@lists) {
for @lists - @list {
take shift @list;
}
}
}
}
But I can't tackle the lvalue problem.
btw, I'm defining the semantics of some of several functions by simply
supplying a reference implementation.
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
RFC 90 (zip) and RFC 148 (reshape)
Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same? Isn't reshaping the basic operation of interest? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 90 (zip) and RFC 148 (reshape)
Chaim Frenkel wrote: Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same? Yes. RFC 148 can also partition (RFC 91). I've updated RFC 91 to also allow a 3rd argument that gives a step size--I haven't checked whether reshape() can do this. The updated RFCs 90 and 91 don't seem to have been processed yet. Isn't reshaping the basic operation of interest? Yes. RFC 148 is Nate's attempt at generalising RFCs 90 and 91. You can also do all of this using generated lists as list slices (RFC 81). RFC 148 is more complex than RFCs 90 and 91, and RFC 81 is more complex than RFC 148. The issue is whether zip() and unzip() (now called merge() and demerge()) and partition() (now called part()) are used enough to justify giving them their own functions. This is much like how push(), pop(), shift(), and unshift() can all be done with just splice(). The other issue is whether RFC 148 is currently general enough--for instance, whether it will (or should) scale to multiple dimensions effectively.
