Re: Lua life after integers

[Sean Conner <sean@...>]

It was thus said that the Great Andrew Starks once stated:
> On Wed, Dec 10, 2014 at 8:52 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> > 2014-12-10 16:44 GMT+02:00 Rena <hyperhacker@gmail.com>:
> >
> >> Interesting. Why is __tostring not a core metamethod? The distinction
> >> seems arbitrary to me.
> >
> > A core metamethod is a fallback. It is called when Lua does not
> > know what to do, as a last resort instead of throwing an error.
> > __tostring, __pairs etc are called _instead_ of what Lua knows
> > to do.
> >
> 
> I don't make that distinction, even when I'm reminded that the authors do.
> 
> The reason is that, to me, it's meaningless. It works or it does not
> work and remembering where it works and doesn't is not something that
> I care to invest the time to memorize. At best, I know that whenever I
> define `__ipairs`... sort of worry that it may not work, if my table
> is handed to a library that may not honor it. To my way of thinking,
> there are fields that are attached to metatables that begin with `__`
> and end with the name of the method that they modify. Anything beyond
> this, to paraphrase the Bible, is complex.
> 
> I don't know if this is important enough to bring up in another
> thread, but I also don't like the deprecation of `__ipairs`. Whatever
> the redundancy it may suffer, it is clear to the writer or reader of
> the code that a sequence of key/value pairs, iterated in a consistent
> order, is expected. If `ipairs` and `pairs` exist and we allow for a
> way to override `pairs`, then consistency would require a
> corresponding way to override ipairs.

  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?

  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]

> 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.

[2]	What ever happened to Coroutines anyway?