Re: New array type? (was: 'table' as fallback for tables)

[Coda Highland <chighland@...>]

On Wed, Jul 6, 2016 at 10:08 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On Jul 6, 2016, at 12:09 PM, Soni L. <fakedme@gmail.com> wrote:
>
>
> Without bloating the table type too much. It's better to add this to the
> table library instead of adding it to the table type. It'll also be easier
> to handle on the C side of things as you won't have to redesign the whole
> Lua VM for a completely redesigned table type.
>
> Actually, if the whole Lua VM were to be redesigned, it'd stop being Lua
> 5.x, instead becoming Lua 6.x. And it'd be slower and heavier, because then
> you'd track size for all tables, not just the tables that need it.
>
>
>
> As I pointed out previously, the overhead is a single 64-bit integer per
> table. Although this might imply an 8 byte overhead, in fact this is free on
> all major platforms that I know of (Windows, Linux, iOS, Android) since the
> granularity of heap allocation means that there is no additional memory
> allocation at all. So there is no overhead at all, apart from setting a C
> integer to zero when a table is allocated. Nor is there overhead when
> adding/deleting table keys (even integer keys).
>
> Why do you think a VM redesign is necessary ?
>
> —Tim

I think part of the issue here is that there are a number of competing
suggestions flying around. Another part is that memory overhead isn't
the only way that something can get heavier.

To ensure that ALL tables track their length under all possible
operations... well, it might be hyperbolic to say it would be a VM
"redesign" but it WOULD require quite a lot of modification, with
possible . And due to the inherent ambiguity in whether some actions
are meant to alter the length of a table (is "t[#t] = nil" setting the
last element of a fixed-size array to nil, or is it reducing the size
of the array? is "t[#t+1] = 1" a push operation or is it writing out
of bounds?) it would require changing the semantics of the language.
And outside of the question of memory allocation, the efficiency
tradeoff (make length calculation cheaper in exchange for making
mutations more expensive) is probably not the right choice for
general-purpose use.

The counterproposal being made is to use the existing language
features to define a type that has a specific set of behaviors for the
scenarios where those behaviors are explicitly desired without making
modifications that would affect the language more broadly.

/s/ Adam