Iterator Performance: Should I use closures, for in or coroutines. Understanding Coroutines

[Veli-Pekka Tätilä <vtatila@...>]

Hi list, Ok I'm going to post three separate questions. And in the hopes of 
making this clearer I'll start them in different threads contrary to what I 
usually do. This one is about iterators:

I've learned I can do iterators in quite a number of ways: the for-in 
contract, closures or coroutines. PErlishly using returned closures to 
maintain state. Relying on the for in contract to hand in me the state and 
updating the variable parameter passed to me based on the value returned. Or 
even by wrapping a coroutine keeping any state in the function call and 
merely reentering the function in the middle to cary on processing to put 
this vaguely in natural language.

In cases where the overhead of fetching the next element is very low,  which 
of these idioms should I use in terms of performance, and does it really 
matter in most cases anyway? ALl of them feel quite useful and natural 
depending on the context. Closures are the most familiar to me from Perl, 
coroutines are elegant to write once you understand them, and the "for in" 
contract version is probably easiest to grasp for folks new to dynamic 
typing who'll be reviewing my code.

On a side note, though I understood how yield works in Ruby the PIL 
explanation in Lua didn't make things very clear for me personally. Rather 
than necessarily viewing it as threading, though it can be used for it, I 
tend to tthink of coroutines as library level support for returning to the 
caller early and means of continuing from where you left off. Resume then is 
the way to really call the function initially, the blocking yield escapes 
back to the caller analogously to a return, and subsequent resumes re-enter 
the function, returning from yield. BOth resume and yield can then, exchange 
any parameters much like calling a function and returning from a function 
can. The way I've understood it, the whole point of coroutines is the early 
escape to a caller, and since the function has not finished until it returns 
for real, the ability to easily keep a lot of state in the function itself. 
As you can get to the caller, you may decide exactly which coroutine to 
resume next, or even have multiple "instances" of the same function all 
waiting for their yield to return. IT comes down to how you think, I rather 
like vague natural language explanations myself, but I do know not all 
people do. Some like code, others math, and once I know a language, I'm very 
fond of the K&R style brief docs for functions.

--
With kind regards Veli-Pekka Tätilä
Accessibility, Apps and Coding plus Synths and Music:
http://vtatila.kapsi.fi