Re: Lua 5.4-work1 with first class arrays (implementation & benchmarks)

[Dirk Laurie <dirk.laurie@...>]

2018-03-30 21:37 GMT+02:00 Petri Häkkinen <petrih3@gmail.com>:
>
>> On 30 Mar 2018, at 12.14, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>
>> I copied the Makefile from the lua-5.4.0-work1 distribution and 'make
>> linux' works after I also copied over luac.c.
>>
>> That Makefile has production settings: -O2 and -DLUA_USE_LINUX" but
>> not AFAICS error checking.
>>
>> I still have to incorporate your TESTS targets
>
> They are not mine. The TESTS stuff in the makefile come from the official lua github repository.
>
> As long as you’re using -O2 and no error checking you should be good to go.

I have found a bug:

     function arr(...) return [...] end; print(#arr(1,2,3,4))   --> 0

Here is a summary of changes from a Lua programmer's point of view
(some of them may be implementation details or even bugs):

1. An array is a table with the restriction that keys may only be
positive integers. This restriction cannot be sidestepped by using
'rawset', but a __newindex metamethod that e.g. stores values in a
proxy table is still respected.

2. Arrays are constructed by the syntax
   '[' explist ']'

3. The default length of an array (in the absence of a __len
metamethod) is not determined by the built-in border function, but by
looking up a stored unsigned integer initialized by the table
constructor. This length can be changed in two ways:
  * by assigning any value, even nil, to an index greater than the length
  * by calling a new function table.resize. After doing this, you can
still store outside the declared length, and retrieve those values,
but the redefined length is frozen, i.e. it can no longer be changed
by assignments (this may be a bug rather than a feature, but I like
it).
  * table.resize can be called with any table as argument, but it only
has an effect if the table is an array.

Conceptually, array is a subtype of a table, like integer is a subtype
of a number.

Imagining myself to be as I was seven years ago, a Python programmer
with no prior experience to Lua, I would have had a warm feeling of
familiarity with arrays, although mildly puzzled at why they start at
1. But now I am a Lua programmer with a dim recollection of Python,
and I wonder why I would want to use these arrays. They come with a
motivation that they are more efficient: that has never impressed me
much, otherwise I would have been a LuaJIT programmer.

But let me for the sake of argument concede the point that arrays in
Lua would be nice to have.

There are two things that I would change from the current de-facto
behaviour (there is as yet no manual-style specification).

1. No array subtype; 'array' is a property of a table. This implies no
prohibition of non-integer indices.
2. Once length has been frozen, assignment to a too-large integer
index is an error.

The first of these makes it desirable to add a lot of extra
functionality to table.resize.

  * The array constructor sets the array property but does not freeze
the length: assignments can still change it.
  * table.resize(tbl,n) with n>0 turns any table, including an array
with frozen length, into an array of frozen length n.
  * table.resize(tbl,0) unfreezes table length.
  * table.resize(tbl,true) turns a table into an array and freezes its
length at the current #tbl.
  * table.resize(tbl,false) turns an array back into an ordinary table.
  * table.resize(tbl) returns false if the table is not an array, true
if it is an array but length has not yet been frozen, current length
if it has been frozen.