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

[Petri Häkkinen <petrih3@...>]

> On 31 Mar 2018, at 8.31, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 
> I have found a bug:
> 
>     function arr(...) return [...] end; print(#arr(1,2,3,4))   --> 0

Thanks!

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

This is indeed a bug.

The concept of freezing arrays is interesting. But as a side-effect to table.resize() it’s misleading. Perhaps there should be a new function or metamethod for freezing the array.

The possibility of having named fields in arrays is definitely a possibility, but I wanted to keep the semantics and the patch as simple as possible for this experimental proof of concept.

Thank you for the nice summary and trying it out!

Petri

—

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