But massive overkill, I'd think.

Why not just get the user to pass you a reference to a lexical you can use to store your magic? Or even use as your key...

The iterator syntax is cute, but is it worth that much effort? It would likely break at every point release, and I don't think you'd get much buyin from p5p for adding tests to make sure this kind of stuff keeps working from release to release...
--
Mike

I'd just like to be able to write operators that act like any other builtins. The limitation isn't stopping me from doing anything I need to do. It just irks me that you can't do it. It just seems to me that I should be able to say somthing like

while( my @els = elements @array,3){
   .. do something
}

# instead of 

my $iter = make_iter(@array);
while (my @els  = @{ $iter->() } ){
   .. do something
}
[download]

I would also think that it might solve part of the problem of implementing coroutines and continuations.

Excuse my ignorance, what do you mean by "point release", do you mean newer versions of perl? I would think that behavior wouldn't change that much but I honestly have no idea.

-Lee

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

It just irks me that you can't do it. It just seems to me that I should be able to say somthing like ...

... this?

{
    my $pos = 0;
    sub elements(\@$) {
        my($ar, $n) = @_;

        my $range = $pos + $n < @$ar ? $pos + ($n - 1) : $#{$ar};
        my @ret = @$ar[ $pos .. $range ];
        $pos += $n;

        return @ret ? @ret : ();
    }
}

my @ar = qw(
    foo bar baz
    one two three
    ichi ni san
    xxx
);

while(my(@chunk) = elements(@ar, 3)) {
    print "got: @chunk\n";
}

__output__

got: foo bar baz
got: one two three
got: ichi ni san
got: xxx yy
[download]

Or am I missing the point?
HTH

_________
broquaint

A conversation regarding user-perl hidden lexicals popped up in the chatterbox recently. There was a thought that if you prepend the variable name with '&' then it is effectively inaccessible from user-side perl. The rest of the conversatin wasn't relevant but that's still an interesting idea. I still don't understand internals well enough to know what happens to PADLISTs on entering/leaving a lexical scope but hey...

Or... on further consideration now that you're potentially stomping on other people's lexicals I would think that your variable key should also incorporate some disambiguation between individual instances of yourself - consider including your own address in the variable name so if the user starts two iterators then both don't write on each other. Obviously this raises other concerns about circular references - your iterators are now responsible for cleaning up every CV context you've been in on iterator destruction (looks like you should turn that into an object now).

My thinking on the lexical naming of the var that is hidden in the scope would be a \w friendly mangling of the function and it's args. That way you could have multiple calls in the same scope.

Just to clarify, because my example did not is that I'm interested in Lazy Iterating.

-Lee

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

And if your function is called with the same arguments in a different instance? You can use line number to disambiguate between instances that aren't on the same line but I'm not sure how you keep track of different instances with the same arguments on the same line. Unless... keep track of the specific instances of your arguments - pointers perhaps. Those are only four bytes (on my platform anyway) and would be cheap to keep track of. If you do this I'd like to see the code.

I agree that it would require something more to make it work as well as the builtins, perhaps an Attribute that tells the compiler to add an implicit parameter for you.