[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Coroutines & Iterators
- From: Alex Bilyk <nebula-crl-2688@...>
- Date: Wed, 08 Jan 2003 00:28:05 -0800
Why would anyone assume that coroutines have something to do with
iterators beats the life out of me. Coroutines, as far as I get them,
are related to the concept of multithreading, which, in turn, relates to
how various parts of code get executed. I would not make any assumptions
on ways people will use them as they can be useful for a myriad of
things. If the iterators are one of such things, so be it. But to say as
I have a suggestion for Lua5. I'd like to suggest that some syntactic sugar
would offer a different--and potentially better--mechanism for iteration
than couroutines. Bear with me for a moment while I explain!
The idea is to have slightly different sytax for anonymous functions--and
to have special parsing for such anonymous functions when they follow a
function call. (This is similar to what Ruby does, and what Ruby does is
similar to what Smalltalk does. Well, sort of. Not really!)
That means that instead of this:
x:somefunction( x, y, function (i) print(i) end )
You'd have something like this:
x:somefunction( x, y ) do |i|
Why is this better?
It seems like Lua5 is headed toward using coroutines for iterators.
"It seems like Lua5 is headed toward using coroutines for iterators."
seems a bit too much.
Coroutines are, by comparison, relatively heavy-weight objects. Indeed,
coroutines effectively have their own stack and state and are generally
allocated from the heap.
Everything I've shown above works from the current stack. Again, this is
simply syntactic sugar for something that's already possible in Lua4: call
a function, and let that function call a function which is passed in. Very
simple--and very quick. In more ways than one.
The new "for" syntax in Lua5 can *almost* do this. There are three issues:
* first, as I said, it seems to assume coroutines, which are relatively
No, it does not assume this and therfore allows to work from current stack.
Firstly, not a coroutine but a generator function doesn't have to be a
coroutine. Secondly, tt doesn't assume that "one var" thing, it's the
protocol design that seems to be good enough IMHO.
* second, it assumes that the coroutine will produce at least one var;
* third, it implies (by using the suggestive "for ... in ..." phrasing)
iteration--but you don't always want to iterate, sometimes you just want to
I am passing this one as I don't know what this "wrap" is about.
This would be my opinion as well. But one would use them for iteration
by choice not out of necessity dictated by language constructs.
Coroutines are good--I'm not advocating their removal--but I think they're
overkill for iteration.
The way the "for" construct is set up now makes no assumption on what is
iterated and how. Lua tables are not the only things that can be used in
for loops. For example, one can iterate through C/C++ contaners with
current "for" construct or generate sets of numbers with some algorythm
that has nothing to do with any containers at all. It doesn't seem we
could to such things with "for" constructs in earlier versions of lua.
And, what's more, I think the "syntactic sugar"
would help to encourage a style of programming that was intended with the
original foreach() and foreachi() functions.
Just my $.02