Iterators on Coroutines in Lua | |
Iterator in Lua is what one can put after «in» keyword in | |
«for … in» structure. The general syntax of the struture is: | |
for var1, var2, ..., varN in f, s, i do ... end | |
Here `f` is an iterator. It is usually encoutered in this form: | |
for var1, var2, ..., varN in g() do ... end | |
Here g() evaluates into (f, s, i). I am not going to make a | |
distinction between `f` and `g`, both are iterators. | |
The question is when iterators are better to write on coroutines? | |
In PiL[1] the resone for coroutines is quite terse: | |
>>> | |
With this feature, we can write iterators without worrying about | |
how to keep state between successive calls to the iterator. | |
<<< | |
Producer-consumer example is also good, but not very expressive (for me). | |
Lets first look at the iterator that could gain little if coroutines added. | |
The iterator's state here is the input array and some iteration index. | |
take_one.lua | |
The next goes an iterator that generates permutations of an array. | |
Surprisingly enough it uses take_one() for this: | |
permute.lua | |
In two words it works like this. For each take_one() step it starts | |
iterating over all tail's permutations. Looks simple if no need to | |
think about the iterator's state, but what if rewritten with no | |
coroutine? Its state is a visible structure in this case: | |
permute-explicit.lua | |
It is good to see the iterator's state, but the algorithm readability | |
is traded for that. | |
[1] Pil 9.3 (1st ed.), 2003 | |