Raku / old-design-docs

Raku language design documents
https://design.raku.org/
Artistic License 2.0
124 stars 36 forks source link

How to (lazily) combine elements of two Lists? #18

Open pmichaud opened 12 years ago

pmichaud commented 12 years ago

General question: Suppose I have two lazy Lists @x and @y, and want to create a new (still lazy) List consisting of the elements of @x followed by the elements of @y. What's the canonical form for doing that?

(The underlying purpose of this question is to better clarify the desired characteristics of flattening.)

Possible short answer: Is this the realm of C<.plan>?

@x.plan(@y)    # lazily add elements of @y to the end of @x

Specific example: Suppose I define lists @x and @y as follows:

my @x := (1,2) xx 3;
my @y := (3,4) xx 5;

For this, assume each is as lazy as possible. As Rakudo currently models things, @x is a List that lazily) contains three Parcels, while @y is a List that lazily contains five Parcels.

What's the canonical way of creating a List consisting of the Parcels in @x followed by the Parcels in @y, preserving laziness and without any intermediate Lists or Parcels surrounding the elements?

As mentioned above, if C<.plan> is the canonical answer to this problem, I'm probably fine with that and will continue exploring List refactors based on that answer.

If it's easier or you want to avoid memorializing speculative answers into the Github issue ticket, feel free to propose or discuss possible answers for this in the #perl6 channel.
I'll then transcribe results of those discussions into the ticket as appropriate.

Thanks,

Pm

pmichaud commented 12 years ago

Based on discussion with colomon++ on #perl6, I'll note that .plan as defined in S32 won't do what I want, because its slurpy will end up flattening the arguments (i.e., the Parcels in @y).

Pm

pmichaud commented 11 years ago

From http://irclog.perlgeek.de/perl6/2013-05-30#i_7130528:

01:51 <TimToady> pmichaud: re issue 18, offhand it looks to me like Array.plan is really Array.plan-elems due to the slurpy, but maybe List 
needs both a .plan-elems and a .plan-args, or maybe List.plan is really list.plan-args and the flattening decision is deferred 
to whatever eventually processes the iterator (as with the old .getarg vs .getelem proposal)