Re: Next Version of Lua?

[Mark Hamburg <mark@...>]

The argument for having support for __iter is that if one starts to  
build iterations via sequences of filters, maps, and so forth then  
__iter allows one to avoid having to tack something on at the end to  
actually convert to iteration form while at the same time avoiding the  
performance costs of going through the __call metamethod lookup on  
every loop iteration.

The expense of doing this is the extra opcode at the beginning of a  
for loop to see whether the first argument to the for loop has an  
__iter metamethod and if so calling it.

This arguably comes down to a question of how much Lua should embrace  
an object-oriented approach to operations and how much it should stick  
to a more procedural/functional approach. __iter suggests that we  
think about for as taking iterable objects.

While on the subject of iteration, at the expense of probably breaking  
a number of iterator implementations, it seems like it would be nice  
if one could signal done by having the iterator return nothing instead  
of nil. That way one could build iterators that did in fact return  
nil. I don't have a good example of usage handy, but imagine wanting  
to return just the values in an array over a range. The work around  
right now is to return an extra initial parameter and simply ignore it.

In particular, here is a semi-desirable use case:

	for v in ... do
		-- process varargs
	end

This doesn't iterate the varargs because it actually means use the ...  
parameters as the arguments. Hence, we probably need some other syntax  
anyway such as:

	for v in iter( ... ) do
		-- process varargs
	end

It isn't a huge burden to have this also return an index which can  
then be ignored, but the index might be seen as a distraction:

	for _, v in iter( ... ) do
		-- process varargs
	end

With or without the change to support nil values from iterations, some  
way to iterate (and for that matter index) ... would be really nice  
since use of select tends to lead to quadratic time complexity.

Mark