Re: Changes to iterators in 4.1-work4

[RLake@...]

I hate to keep on about this, but I proposed a generalised iterator patch
some time ago,
in http://lua-users.org/wiki/ExtendingForAndNext

The implementation I proposed (well, actually implemented for Lua 4.0)
calls the function
as though it were next; in this way, it is not necessary to maintain
closures. In effect, you
can use k for whatever state you want to maintain, knowing that it will be
passed to the next
call to the function.

It also provides a "next" tagmethod, which is incredibly useful IMHO.

Timing results are available on the page referred to; I think it does
significantly better than what Edgar's results show.

There are also a number of examples of iterator functions and of generator
functions to go along with them. Enjoy! Of course, they won't work with
Lua4.1work4 because they all depend on receiving arguments. :-(

Rici

PD: I'm rushing around a bit today... I apologise if the above did not
sound like "constructive criticism". I do think that Lua is getting better
all the time.

R.


Edgar Toenig escribió:

> Calm down ;-)  Sure, it's nice.  But it's not for free - it's
> pretty heavy weight.  Because the for-statement does not manage
> any state for the iterator one has to create a closure each time.
> I.e. your indexiter creates three (short living) GC'ed objects.
> And the function call costs too.  Something one should realize
> when using this feature.

Yes, I think my patch is better *g*

> Some numbers about the loop overhead:

> function iter(t)
>   local i=0
>   return function() i=i+1 return t[i] end
> end

> local t={"a","b","c","d"}
> for i=1,1000000 do
>   --for j=1,getn(t) do local j=t[j] end    -- Lua: 12.0s
>  --for j in iter(t) do end                -- Lua: 28.2s (includes ~4900
gc cycles!)
>  --for j=1,t:getn() do local j=t[j] end   -- Sol: 10.8s (dispite old
vm?!?)
>  --for j over t do end                    -- Sol:  4.1s
> end