Re: Lua life after integers

[Andrew Starks <andrew.starks@...>]

On Wed, Dec 10, 2014 at 11:32 AM, Sean Conner <sean@conman.org> wrote:
>   To recap:  in Lua 5.2, ipairs() will attempt to call __ipairs(), which
> should return an iterator function, self and an initial value; otherwise,
> ipairs() supplies the iterator function, self and an initial value.
>
>   The default iterator function goes from index 1 until self[index] returns
> nil.  I suspect that most (if not all) iterator functions returned from
> __ipairs() will do the exact same thing, although it doesn't have to be:
>
>         mt =
>         {
>           __ipairs = function(t)
>             local function iter(s,k)
>               if k == -1 then
>                 return 'one',"ONE"
>               elseif k == 'one' then
>                 return 'two',"TWO"
>               elseif k == 'two' then
>                 return 'three',"THREE"
>               else
>                 return nil
>               end
>             end
>
>             return iter,t,-1
>           end
>         }
>
>         x = setmetatable({},mt)
>
>         for index,value in ipairs(x) do
>           print(index,value)
>         end
>
>         one     ONE
>         two     TWO
>         three   THREE
>
>   At this point, you could use __pairs().  Okay, ipairs() could then check
> to see if the initial value returned from __ipairs() is '0' (the default
> value if __pairs() doesn't exist) but then, why even bother with __ipairs()?
> I suppose it *could* check for an integer initial value, but then, is it
> then a sequence as Lua even defines it?  Is that an issue? Consistent even?

This is a good point. If the intent is to override __ipairs, then it
*should* return an __ipairs-like result. Integers, preferably starting
at one and preferably values that are not nil.

>   I know, there's signalling intent.  But the default iterator from ipairs()
> supports __index, and in Lua, a sequence for ipairs() is defined as a
> sequence of integer keys from 1 to n with non-nil values.  [1]

Hmm. I see your (the author's presumably, as well) point. The same
effect may be had, except that there is no longer a way to continue
after the value is nil, except by using some other mechanism, such as
a while loop.

There may be other side effects.
>
>> I may be misunderstanding this issue and I may be mistaken about 5.3
>> deprecating it. If I am correct, then it appears to me that the
>> evolution of Lua is such that  eradicating redundancy is valued over
>> consistency. "Consistency" can be argued about (see math library
>> change).
>
>   If that were true, then ipairs() would be removed as you can always do:
>
>         for i = 1 , #t do ... end
>
>   -spc (Viewing this from a userdata perspective ... )



>
> [1]     I would really expect Thiago, Rena and Coroutines [2] to be upset
>         over the removal of __ipairs() as (to me) they seem like the type of
>         people that love overriding how the language works.

Perhaps you may be conflating monkey patches and metamethods?

Given my lack of appreciation for the fact that ipairs respects
`__index`, my post makes more sense. To my credit, I anticipated this
and peppered my post with "to me" and "if I understand this
correctly." :)

I remain skeptical, but given the above (which I failed to locate in
my very brief scan over prior emails), it seems like a very natural
and logical change.

It's just the sort of terse solution that reminds you that Lua is
authored by people who live in the world of mathematics.

-Andrew


> [2]     What ever happened to Coroutines anyway?
>

* I don't pretend to know, but I recognize the pattern in my own
behavior. Engage. Obsess. Go too far. Retreat. Repeat.