Iterators ..... and closures

Almost every programming language supports some sort of construct to do iterative work i.e. loops. Even functional languages that most often relay on recursive processing provide such constructs. In pseudo code it looks like this :
for variable from 0 to 10 do
	result = result + variable
end
OR
result = 0
while result <= 10 do
	result = result + 1
end
This as expected will calculate the sum of the numbers from 0 to 10. Of course this is very simple example, the general idea though is that you use loops when you have to do some process or calculation over on over again.
So far so good, but very often the iteration is not so simple, you may want to follow more complex pattern of iteration which could not be accommodated by intrinsic loop controls of the language.
The natural extension of this line of thoughts are the so called Iterators. As we saw with the previous examples the loops are centered around a "sort-of-a-index" variable, this variable is used to encode the current state of execution. So Iterators are kind of black box state machines.
For illustration of this concept I will use Perl programming language.
Normally Iterators are implemented via another powerfull mechanism available in Perl, namely Closures. So as you may expect I will have to first explain what is Closure and how it works.
Let's take one example :
sub get_counter {
	my $begin = shift;
	return sub { ++ $begin }
}

my $counter = get_counter(10);
my $counter2 = get_counter(5);
print $counter->(),"\n";
print $counter2->(),"\n";
print $counter->(),"\n";
This will print :
11
6
12
Here is how it works, when we call get_counter() the $begin variable is set to the value we pass (10 in the first case and 5 in the second), then it returns a reference to anonymous function (i.e. this function is not executed immediately). Now $counter and $counter2 point to two functions which will increment the $begin variable whenever called, but here is the clever part, every anonymous function has access to its own different-$begin variable. In computer terms the function lexical scope was preserved, because a reference to copy-of-$begin still exists (Perl would not free up the variables memory, if there is reference still pointing to them).
Now come the next part, later when you call $counter->() /ref to func/ it will increase its copy of $begin by 1 and return it back, so we can printed it the screen. I think you can follow the rest of the logic from here...
If you look more closely you may intuit that what we are doing here very close resembles the initial examples of loops and you will be right to think that. We can call the counters we produced Iterators, but there is just one more small addition we would like to add to call it Iterator. The problem with get_counter() counter is that we can go to infinity i.e. we don't have a limiting condition. Of course it is easy for us to do this check manually f.e. :
my $c = get_counter(0);
while ((my $i = $c->()) <= 10) { print $i }
will print from one to ten, but as the patterns we want to follow get more complex we often are better off if we incorporate the check in the Iterator itself. Here is how to modify our example :
sub get_counter {
	my ($begin,$end) = (shift,shift);
	$counter = $begin - 1;#step back
	return sub {
		#we reached the limit
		return undef if $counter >= $end;
		#first increase the counter and return the new value
		return ++ $counter;
	}
}

In this case our example changes to :

my $c = get_counter(1,10);
while (my $i = $c->()) { print $i };
We now have pretty clear picture of how basic Iterators work. Now lets discuss the reason I decided to write this article... recently I had to use slightly modified Iterator, which I have not seen discussed anywhere... it may be me, I just have not stumbled upon it. What I'm talking about ? Let me show you :
sub get_cursor {
	my ($self,%a) = @_;
	my $begin = $a{begin} - 1;
	my $end = $a{begin} + $a{steps};
	my $counter = $begin;#make a local counter
	return sub {
		#special behavior: gimme back the current value of the counter
		return $counter if $_[0] eq 'pos';
		++ $counter;
		return undef if $counter == $end || $self->is_eods($counter);
		return $self->get($counter);
	}
}
Nothing fancy almost the same like our examples... except the "special behaviour" line...
The reason for adding this line is that I needed the iterator to carry more information for me, it is a "black-box" anyway and in my situation it made alot of sense. It is much better to carry more than one thing which describes the state of iteration in an encapsulated way, rather than carring bunch of variables around.
I could have easily just stored the index as I go and then pass it around and then use it when I need it. But if instead I pass the iterator itself with some more baggage in this case was the better solution !
That is exactly what I did ... i.e. if I do a normal call like this :
my $it = $obj->get_cursor(begin => 100, steps => 10);
then I can loop over calling $it->(), over and over...but let say after the fifth iteration I do this :
my $current_pos = $it->('pos');
the Iterator won't get incremented, but will instead return its current value. Thus I don't have to copy around the index-counter, but can rely on the iterator to provide whenever I need it. It just happened that a little later I needed also to be able to access the initial value(i.e. $begin), one more line and I was done ;).
Even this is not a big deal, the big plus is the IDEA to make the Iterator provide you with more information about its current state.
What if for example you used the closure to carry contextual information about the environment.
The possibilities are endless... just as everything else don't overuse it.

the end ;)