{
    my %position;
    sub elements(\@;$) {
        my $arr = shift;
        my $amt = shift || 1;        
        if(not exists $position{$arr} or $position{$arr} < $#$arr) {
            my ($start, $next) = ($position{$arr}, $position{$arr} += 
+$amt);
            return @$arr[$start .. $next - 1];
        }
        else {
            delete $position{$arr};
            return;
        }
    }
}
[download]

Makeshifts last the longest.

Along those lines. I don't like the idea of it leaking across scopes. The version I have is a little different. It actually stringifies the reference and caller info to avoid collisions. Using only the ref causes side effects at a distance.

my @array = (1..12);
while(my @els = elements @array, 3 ){
    last if grep { $_ eq 2 } @els;
}

my @five = elements @array 5; # Would get (4,5,6,7,8)!DWIM
[download]

Using both fixes this problem but can still suffer if the iterative construct is exited prematurely.

{
    while (my @els = elements @giantarray, 10 ){
        # Do stuff    
        last if $els[0] == $somecondition;
    }
    redo if $someothercondition;

}
[download]

The later probably almost never occur in most code, but when it does, I'm sure it would take much head scratching before deciding where the problem lies.

-Lee

"To be civilized is to deny one's nature."

How about you do as Perl's own each then? It will "leak" the iterator all over the entire program as well - but you can call keys or values to reset it.

Makeshifts last the longest.

I don't suppose this satisfies your criteria? It works, but would screw up if you tried to nest uses of it.

#! perl -sw
use strict;

{
    my $next=0;
    sub elements(\@$) {
        my ($ref, $count) = @_;
        my $max = $#$ref;
        $next=0, return if $next > $max;
        my $first = $next;
        my $last = $next+$count-1;
        $last = $max if $max < $last;
        $next += $count;
        @{$ref}[$first .. $last];
    }
}

my @letters = ('a'..'z');
while(my @els = elements(@letters, 5) ) {
    print "@els\n";
}
__END__
a b c d e
f g h i j
k l m n o
p q r s t
u v w x y
z
[download]

What I did in this case was use a hash so there could be multiple instances. The hash key was the stringified args and a join of caller. It almost always works but there are several potential problems.

If this could be solved generically, then I think you'd be able to implement basic "coroutines" as I understand them. You'd still have to wrap up the start executions in if's or something but it would be a start.

-Lee

"To be civilized is to deny one's nature."

I did play around with some stuff that generated iterator subs on the fly here RFC and debugging tips. That allowed you to use multiple independant iterators. When the handle to the iterator goes out of scope it gets thrown away, bit I think that is getting oo-ish which isn't what your looking for.

Oh well. I guess I came to the party late and should have read back over the thread before commenting.

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.