Re: table library changes (was Re: table.new in 5.3?)

[Philipp Janda <siffiejoe@...>]

Am 24.11.2013 14:12 schröbte John Hind:
> Dirk and I had a serious go at worrying at the table library a few months back and here is what I came away from that experience with (aside from the bruises which have not yet completely healed!)
>
> 1. The current table library is not a table library, it is a list library. But there is a lot of stuff in the basic functions that ought to be moved to a table library (or retired).

I'd call it array library because I associate the term "list" with 
single- or double-linked lists.
But then there aren't that many essential non-array functions on tables 
... I'd be ok with `raw{g,s}et` and `next` moving to the table library 
(or even the debug library), but e.g. `pairs` and `ipairs` certainly 
belong to the base library, IMHO.

> 2. 'ipairs' and its associated metamethod are redundant - just use the numeric form of 'for'. This realisation suggests a re-evaluation of the approach in my "Self-iterating Objects" powerpatch.

I disagree. The numeric for loop is a second class citizen: you can't 
pass it to (or return it from) a function (which sadly is still not 
being done very often in the Lua code I've seen -- the recently released 
lua-fun being a notable exception). Whenever you pass a table as input 
to a function, consider passing an iterator triplet instead. This way 
you can use the function for `pairs()`, `ipairs()`, `filter(p 
,pairs())`, map(f, ipairs())`, and possibly other data sources. At some 
point in the future I'd like to see a merge of iterators and LTN12 
sources and sinks.
The only reason for the continued existence of "numeric for" is its 
superior performance compared to a `range` iterator function.

> 4. Everything except 'sort' can be done (almost) as efficiently (and to taste) in Lua. It would be useful to have 'sort' surfaced in the C API as well as a Lua library function.

What makes `table.sort` different? Certainly you can implement an 
efficient sort routine in Lua (and it has been done before[1]). I'd say 
`table.unpack` and maybe `table.concat` are the only functions in the 
table library deserving a C implementation.

  [1]: http://permalink.gmane.org/gmane.comp.lang.lua.general/99485

> My approach is to remove everything except 'sort' from the 'C' table
> library and use my own Lua implementation with an OO approach to
> wrapping table as Table, List and Set classes. But it still bothers
> me that the current metamethod design does not allow me to intercept
> assignments that would break the objects (changing an existing List
> value other than # to nil, assigning other than 'true' or 'nil' to an
> existing Set member.)

You can solve that using proxy tables. I've been toying with the idea of 
using different "views" on a table. A "set" view (proxy table) would 
translate values to boolean on __index (`true`/`nil` on `__newindex`), 
return only trueish values via __pairs, and raise errors for operations 
that don't make sense for a set. Of course `ipairs()` and its metamethod 
are used to implement the "array" views (which of course also intercept 
the invalid assignments you describe). A single table could be the 
backend for multiple different views, and the type of view you use for 
access determines which operations are valid and how the values are 
translated between view and backend table.

Philipp