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 Cted stuff is pushed and that this is returned upon either
explici
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 {
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 writes:
> Better documentation on gather/take is merited.
Without a doubt.
> I would question the need for C, however. Could not a lone
> C/C force the return value of the enclosing routine/closure
> to be a lazy list, and here's a few values to get things started?
C is necessary. C
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 result
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
> > b
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 mi
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 ent
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 th
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 sing
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 th
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 single map.
To propose one w
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
