Re: idea: __iter generic-for metamethod

[Jonathan Castello <twisolar@...>]

On Mon, May 24, 2010 at 3:52 PM, Stuart P. Bentley
<stuart@testtrack4.com> wrote:
> There were some posts a few days ago that were nested several deep in a
> discussion on ipairs [1], in which the idea was brought up of using a
> different approach to metamethods for the generic for than the current
> working proposal of __pairs and __ipairs. I felt that the idea should be
> brought to the forefront, so I've written up a more formal "proposal".
>
> The way I'd conceptualized it was that, when the generic-for encountered an
> iterator that wasn't a function, before raising an error, it would first
> check the metatable for a function at the "__iter" index. If it found a
> function there, it would use it, allowing users to override the iterative
> behavior over an object more simply than overriding its functionality when
> passed to pairs() (or ipairs, even though the manual suggests it should be
> deprecated).
>
> Additionally, you could use this to bring back the "for k,v in t do" syntax
> by making the default function for tables be next() in the event they don't
> have an __iter metamethod.
>
> To put the original concept in terms of the Lua manual's definitions for
> metamethods:
>
> function generic_for_iterate (iter, ...)
>  if ... then -- if the iteration has not completed (iterator hasn't returned
> nil)
>    if type(iter) == "function" then -- got iterator?
>      return generic_for_iterate(iter,iter(...)) --continue iterating with it
>    else -- got some
>      meta_iter = metatable(iter).__iter
>      if meta_iter then -- metatable has iterator?
>        return generic_for_iterate(meta_iter,meta_iter(iter)) -- start
> iterating with metatable's iterator
>      elseif type(iter) == "table" then -- default case for tables
>        return generic_for_iterate(next,next(iter)) -- start iterating with
> the default iterator
>      else --no iterator available: default behavior
>        error("this was an ellipsis in the original manual but I couldn't
> copy it correctly")
>      end
>    end
>  end
> end
>
> Note that I'm not the king of generic for iteration, and if this appears to
> change the semantics of generic for iterators, that is unintentional. The
> goal was to show the logic flow for selecting an iterator with metamethods.
> (It also assumes generic_for_iterate only proceeds after the code inside the
> loop has been evaluated, of course.)
>
> [1] http://lua-users.org/lists/lua-l/2010-05/msg00581.html
>
>

Correct me if I'm wrong - I'm having just a little trouble following
the code - but is this executed for every iteration? I posted an
example a few minutes ago that translates to the current definitions
of the generic and numeric for - so it's really a mapping from pure
syntax to one of the two for's - but I'm not sure where this one fits.

I'm not sure I see where the loop body is getting executed either, but
again, I might just not be following it right.

~Jonathan