[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: ipairs in Lua 5.3.0-alpha
- From: Jan Behrens <jbe-lua-l@...>
- Date: Tue, 19 Aug 2014 12:47:49 +0200
On Tue, 19 Aug 2014 09:36:41 +0200
Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-08-18 21:23 GMT+02:00 Jan Behrens <jbe-lua-l@public-software-group.org>:
> >
> > My main proposal is to allow ipairs to be used as a general
> > interface for (ordinal) iteration.
> > ...
> > If ipairs(...) accepted a function or an iterator triplet (which it
> > currently doesn't do in Lua 5.3-alpha), then ...
>
> Aha! Finally you have put it in a way that penetrates my thick
> and lazy skull.
>
> Well, your proposal is one for which PUC approval is not needed,
> since a simple `ipairs=require"supercool_ipairs"` with an appropriate
> supercool_ipairs.lua in the module path will do it. (In fact, a similar
> comment applies to anything in the standard libraries.)
>
> [...]
> In any case, I could still say `jpairs=require"supercool_ipairs"`
I don't agree. Of course, it's possible to load "supercool_ipairs"
through a module. But if default Lua 5.3 won't support __ipairs
anymore, then which other library would really offer the interface
that "supercool_ipairs" could access?
As I previously said, the true power of a generic iterator interface
is not its implementation/availability of the ipairs function (that
always could be loaded as a module), but the common agreement of how
the interface for iteration looks like. And this requires Lua 5.3 to
stick to the __ipairs metamethod at least. The current plan, however,
is to drop it.
Like I said:
On Sun, 17 Aug 2014 19:26:53 +0200
Jan Behrens <jbe-lua-l@public-software-group.org> wrote:
> Of course, this "supercool_ipairs" could be also implemented outside of
> Lua's baselib. But its true power would be only available if there was
> a general agreement on a common interface (__index, __len, __ipairs).
>
> Otherwise there is a mess (as explained in my previous post) when every
> library defines its own iterator interface.
This is why "PUC approval" and incorporation into Lua 5.3 would really
help here.
Providing "supercool_ipairs" by default (and adding an adequate
API call to Lua's API) could also encourage library programmers to
write their functions in such way that they accept any sequence-like
object where applicable. E.g. json.array(seq) could accept any
iterable sequence-like object: either a literal like {1,2,3}, the
result of file:lines(), or any other raw function or any object that
supports the __ipairs metamethod; it wouldn't make a difference for
the caller).
See also my post from Sun, 17 Aug 2014 15:00:14 +0200:
http://lua-users.org/lists/lua-l/2014-08/msg00500.html
Regards
Jan
- References:
- Speed of # operator (Was: ipairs in Lua 5.3.0-alpha), Dirk Laurie
- Re: ipairs in Lua 5.3.0-alpha, Doug Currie
- Re: ipairs in Lua 5.3.0-alpha, Coda Highland
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Andrew Starks
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Dirk Laurie
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Dirk Laurie
- Re: ipairs in Lua 5.3.0-alpha, Jan Behrens
- Re: ipairs in Lua 5.3.0-alpha, Dirk Laurie