lua-users home
lua-l archive

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

Hi, 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|

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

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.


Just my $.02