Hi,
the proposal below tries to solve the following problems:
1) Lists should in general be lazy
2) There are cases when listy data structures shouldn't have to remember
all their values. A statement like
for 1..1e6 {
.say
}
should *not* store 1 million integers anywhere, any time
3) Other constructs do need to remember old values. For example:
my $result = $str.split();
for @($result) { .say }
for @($result) { .say }
or even
my @result = $str.split()
for @($result) { .say }
for @($result) { .say }
should produce the same output twice, ie $result needs to remember old
values.
Since there is a profound confusion about how things should be called,
I'll mostly *not* use the names from the spec (which I'd probably get
wrong), and instead I'll use:
Iterator # something that doesn't remember old values,
# and can generate new values through a code block or so.
SList # something that remembers values that have been
# evaluated already, and also has a lazy part
# you can't mutate an SList object with $slist[0] = 3;
Array # ye good auld array, the type behind the @ sigil
# obviously has to remember items that have been evaluated
# you can mutate Array items
Here's the proposal:
gather/take and other lazy generators should return an Iterator.
Assigning an Iterator to a variable automatically turns it into an
SList. Assigning to a @-sigiled variable turns it into an Array
Binding an Iterator to a @-sigiled variable turns it into an SList (or
Array? not sure...)
Binding to a scalar container: no idea if anything should happen.
Indexing an SList beyond the stored ("reified") part continues to
evaluate values until either the index location is reached, or the
iterator is exhausted. Values generated that way are stored internally.
list(SList) and list(Iterator) just hand back the argument.
Did I forget anything important?
(Note: currently Rakudo calls the 'SList' a 'Seq', which is probably
wrong. I guess it should be called 'List')
The proposal was the result of a discussion between colomon and me on
#perl6. I hope I didn't confuse too many things :-)
Cheers,
Moritz
