Re: Iterators and the Generic 'for'

[Mark Hamburg <mark@...>]

On Jun 1, 2011, at 5:11 AM, Dirk Laurie wrote:

> On Wed, Jun 01, 2011 at 11:49:59AM +0200, Duncan Cross wrote:
>> 
>> In summary, stateless iterators only work at all for certain simple
>> kinds of iteration anyway (for example, string.gmatch() returns a
>> stateful iterator, it just couldn't work as a stateless one) and the
>> difference in performance with stateful iterators is only likely to
>> come up if you are using them a *lot*, on the order of hundreds of
>> thousands of times.
>> 
> Thanks.  You've set my mind at rest.  

One other difference: Termination. The leading key value even if shoved into a dummy variable allows one to have nil results while without it we can't.

Consider wanting to write a values iterator:

	for v in values( 'foo', 'baz', 3, 7 ) do
		print( v )
	end

This is particularly useful with varargs (values( ... )).

All works well until the values list includes a nil. The nil stops the iterator even if we aren't at the end. If we instead write ivalues which returns the index and the value, this problem doesn't exist.

Mark

P.S. If one felt driven to fix this at the language level, the simplest answer -- though it would break a lot of existing iterators -- would probably be to use returning nothing rather than returning nil as the signal that the iterator was done. I have no idea whether the complexity would balance out better if one did that. There is certainly an argument that for most iterators there are more uses than implementations and hence simplifying usage is better. The syntactic usage cost of the leading key is pretty low, however, and there might well be implementation costs that would hit the runtime for all iterators (and possibly even all iterations) and this would certainly make writing iterators more complicated (in some cases much more complicated).