lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



I personally tend to use a mixture of "for contract" and closures. You don't have to keep the state in the state variable listed in the contract.

As to coroutines, a quick look at your description seems "right". The use of the "thread" word has been argued before (by me and others) in favor of just calling them coroutines.

-asko


On Mon, 30 Jun 2008 10:01:59 +0300
 Veli-Pekka Tätilä <vtatila@gmail.com> wrote:
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