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

[William Ahern <william@...>]

On Thu, Jul 07, 2016 at 08:06:20PM +0200, Dirk Laurie wrote:
> 2016-07-07 18:15 GMT+02:00 Joseph Manning <manning@cs.ucc.ie>:
> > On 2016-Jul-07 (Thu) at 09:08 (+0200), steve donovan wrote:
> >
> >>> It would be cool if #t was O(1), however.
> >
> > Steve,
> >
> >    In theory, yes indeed, this would be nice and neat and clean.
> >
> >    In practice, however, computing #t is blazingly fast.
> 
> The problem that people have with # is not its speed, it is
> the non-determinism. I.e. fixed size is conceptually easy,
> the first frontier is easy, the largest numeric index is easy,
> but some unpredicatable unspecified frontier is sophisticated.

How did "largest numeric index" work when deleting the last index, like when
popping a stack data structure. Did you also assign nil to erase it? If so,
isn't that an inconsistency--assigning nil inside of an array is okay, but
assigning nil to the last index has special truncation behavior? That seems
worse than the current behavior. (I don't mean to imply I have any problems
with the current semantics.)

> The current equivocation, that # is undefined when the table
> is not a sequence, sells it short. The property documented
> in the Lua 5.1 manual, that t[#t+1] is guaranteed to be an
> empty slot, is a useful one, no matter how many newbies
> are puzzled by it.

But for a non-sequence, #t might evaluate to a lesser index after executing
t[#t + 1] = true. What use is the guarantee that t[#t + 1] is empty if you
lose track of that value after the fact?