Re: ipairs in Lua 5.3.0-alpha

[Jan Behrens <jbe-lua-l@...>]

On Fri, 15 Aug 2014 13:37:41 -0300
Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> If the goal is only to reduce calls to length, [...]

Perhaps it was a bad idea to talk about *how* to implement ipairs
efficiently. (Sorry for my part here.) We should first discuss *what*
ipairs shall be.

And before we can discuss what ipairs shall be, we should take a look
what ipairs was in Lua 5.1 and Lua 5.2.


In Lua 5.1, ipairs was IMHO basically syntactic sugar:

On Fri, 15 Aug 2014 19:51:13 +0200
Jan Behrens <jbe-lua-l@public-software-group.org> wrote:

> Wasn't ipairs() initially thought as syntactic sugar (without having to
> bloat the language)? In Lua 5.1, there was practically no difference
> between:
> 
> for i = 1, #t do local v = t[i]; ... end
> 
>  and
> 
> for i, v in ipairs(t) do ... end
> 
> Unless t was not a sequence (in which case #t is undefined),
> or t was a userdata (in which case ipairs wouldn't work).


In Lua 5.2, ipairs became IMHO some sort of interface that allowed
polymorphic treatment of all sequence-like structures:

On Fri, 15 Aug 2014 03:07:16 +0200
Jan Behrens <jbe-lua-l@public-software-group.org> wrote:

> [...] I would say that (since Lua 5.2) ipairs is some
> sort of interface: it allows programs to iterate through "sequence-like"
> containers. In other words:  If your processing function utilizes the
> ipairs iterator, then it doesn't matter if you pass a sequence in form
> of a table or in form of a userdata: both userdata values, raw tables,
> or proxy tables behave all the same when accessed through ipairs. Let
> me give you an example:
> 
> function print_entries(t)
>   for i, v in ipairs(t) do
>     print("Entry #" .. tostring(i) .. ": " .. tostring(v))
>   end
> end
> 
> I may pass a raw table to print_entries, e.g.:
> 
> print_entries({"Hello", "World"})
> 
> But I may also pass some userdata value to print_entries, e.g.:
> 
> print_entries(sql:query("SELECT name FROM person"))
> -- where sql:query(...) returns a userdata value
> 
> The function print_entries behaves polymorphic. It accepts any value
> that supports the ipairs interface (through its __ipairs metamethod).
> The print_entries function does not need to be aware of a special
> iterator function that's part of some SQL library (or another iterator
> function that's part of an an LDAP library, or yet another function
> that's part of a JSON library, etc.). Instead it just uses the common
> ipairs interface.


So in short:

* In Lua 5.1, ipairs was more or less syntactic sugar for the
  arithmetic for-loop on tables with positive integer keys

* In Lua 5.2, ipairs became some sort of interface that allows
  containers (userdata or proxy tables) to behave like sequences.


Maybe I misunderstood the semantics of ipairs in Lua 5.2 here.
(If I did, please enlighten me.)


My question is now (disregarding any implementation issues):

"What shall ipairs be in Lua 5.3?"

Shall it be:

* syntactic sugar for iterating from v = t[1] to t[v]
or
* be an interface that allows other containers to behave like sequences?


Regards
Jan