The way I understand the magicness of lazy lists, I'd expect:
@x = 3..Inf; say pop @x; # prints Inf
@x = 3..Inf;
push @x, 6; # an array with the first part being # lazy, and then the element 6
say pop @x; # prints 6 say pop @x; # prints Inf say pop @x; # prints Inf say pop @x; # prints Inf
# etc
The way I think of a lazy infinite list is kind of like a special object. It needs to keep track of what the start is and what the end is. Every other element doesn't actually exist, but is calculated based on the index of the FETCH/STORE/SPLICE/whatever call.
I guess that's true with X..Y lazy lists. I thought there were other ways to make lazy lists, like giving it a closure that gets called lazily to populate the list with the result's being cached. I can't remember the syntax though. I think gather was one way. Maybe I'm just remembering wrong.
Anyhow, I was thiking that was how X..Inf was implemented. That would be foolish in this case.
how 'bout
@x = gather{
loop{
take time
}
} # can this be @x = gather { take time loop }
push @x, "later";
say pop @x; # "later"
say pop @x; # heat death?
say @x[rand]; # how about now?Also, any list that contains and infinite list becomes tied. The container list's FETCH would change so that any accessed index that falls within the indexes "owned" by the infinite list would be dispatched to the infinite list. So, with a list like:
@array = ('a','b','c',2..Inf,"woops");
Elements 0, 1, and 2 would be accessable as normal, but then elements 3 through Inf would be dispatched to the infinite list. However, since "woops"'s index is also Inf, and that index is "owned" by the infinite list, it would be impossible to access it except through a pop call (which doesn't look at indexes at all).
I was wondering about lazy list where we don't know how many element it might generate. Admittedly, I picked a poor example. I would right to assume woops would also be accessable with @array[-1], right?
Dan
