Re: Coroutines & Iterators

[Alex Bilyk <nebula-crl-2688@...>]

Hi,
MichaelL@frogware.com wrote:

> 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|
>    print(i)
>  end
>
> [skipped]
>  
>
> Why is this better?
>
> It seems like Lua5 is headed toward using coroutines for iterators.
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 
much as

	"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
> heavy objects;
No, it does not assume this and therfore allows to work from current stack.

> * second, it assumes that the coroutine will produce at least one var;
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.

> * third, it implies (by using the suggestive "for ... in ..." phrasing)
> iteration--but you don't always want to iterate, sometimes you just want to
> "wrap".
I am passing this one as I don't know what this "wrap" is about.

> Coroutines are good--I'm not advocating their removal--but I think they're
> overkill for iteration. 
This would be my opinion as well. But one would use them for iteration 
by choice not out of necessity dictated by language constructs.

> 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.
>  
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.

> Thoughts?
Just my $.02
AB