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.
