On Sat, 18 Sep 2004, Luke Palmer wrote:
Example above becomes:
sub MediansBy5 ([EMAIL PROTECTED]) {
while @list.length = 5 {
emit (sort @list.splice(0,5))[2];
}}
That's actually a very good idea. That's why Perl 6 has it :-)
sub MediansBy5 ([EMAIL PROTECTED]) {
gather {
On Sat, 18 Sep 2004, Rod Adams wrote:
2. Should a subsequent implicit return behave differently than usual if
some values have already been emitted?
It seems clear to me that behind the scenes there should be a stack into
which Cemitted stuff is pushed and that this is returned upon either
Luke Palmer [EMAIL PROTECTED] writes:
That's actually a very good idea. That's why Perl 6 has it :-)
sub MediansBy5 ([EMAIL PROTECTED]) {
gather {
while @list = 5 { # there's no .length; it's .elems
take (sort @list.splice(0,5))[2];
}
}
Rod Adams [EMAIL PROTECTED] writes:
One solution I see to this would be to have a lazy return of some
kind, where you can send out what results you have so far, but not
commit that your execution is over and still allow further results to
be posted. For lack of better word coming to mind,
Jonadab the Unsightly One writes:
Rod Adams [EMAIL PROTECTED] writes:
One solution I see to this would be to have a lazy return of some
kind, where you can send out what results you have so far, but not
commit that your execution is over and still allow further results to
be posted. For
Luke Palmer wrote:
Jonadab the Unsightly One writes:
Rod Adams [EMAIL PROTECTED] writes:
One solution I see to this would be to have a lazy return of some
kind, where you can send out what results you have so far, but not
commit that your execution is over and still allow further results
Rod Adams writes:
Better documentation on gather/take is merited.
Without a doubt.
I would question the need for Cgather, however. Could not a lone
Ctake/Cemit force the return value of the enclosing routine/closure
to be a lazy list, and here's a few values to get things started?
Cgather
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire pipeline down to a single map.
Even for map and grep this
On Tue, 2004-08-31 at 14:11, Sean O'Rourke wrote:
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire pipeline down to a single map.
Even for map and grep this
Aaron Sherman wrote:
On Mon, 2004-08-30 at 16:34, Rod Adams wrote:
@x = @y == map lc == grep length == 4;
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire pipeline down to a
to construct my own map like functions,
and have creating them with pipeline performance in mind to be easy.
Just a thought, since with the creation of == and ==, pipelining is
bound to become an even more common construct.
-- Rod Adams
Randy Sims's test case:
#!/usr/bin/perl
use strict;
use
On Mon, Aug 30, 2004 at 03:34:20PM -0500, Rod Adams wrote:
: My question is, is there anything that can be done within Perl 6 to help
: alleviate this issue.
All lists function lazily if they can in Perl 6.
Larry
13 matches
Mail list logo
