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

[Tim Hill <drtimhill@...>]

> On Jul 6, 2016, at 11:30 PM, Coda Highland <chighland@gmail.com> wrote:
> 
> 
> 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.

Understood, which was why my suggestion was to simply make the length user-defined and that was that for the language per se. No magical changes to length as a result of manipulating table contents. Just a user-settable length that can be read via #t, and respects metatables. Storage overhead we’ve discussed, code overhead is tiny, and in fact deletes the current code behind #t replacing it with a simple read of a stored value (in O(1) time).

Now, it *might* be desirable to have some library functions automatically set the length. For example, pack(), insert(), delete(), so yes there are some library changes. But there is no VM re-design and certainly no impact on the C API. Even these changes are pretty trivial.

However, as has been noted, lots of code breaks, which is not nice at all. If it were not for this I’d push hard for a simple scheme like this one. Let’s face it, the whole issue of #t and sequences and nils comes up again and again and again here .. it really is one of the least intuitive parts of Lua.

—Tim