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

[Dibyendu Majumdar <mobile@...>]

On 27 March 2018 at 17:38, Petri Häkkinen <petrih3@gmail.com> wrote:
> Bumping this thread just this once, as I find the lack of interest on this strange...
>
> Is no-one else interested in O(1) implementation for the # operator, native (faster than tables) array implementation and how it can be used to solve the hole issue and issues with pack/unpack?
>
> I think an array type is the right way to go for Lua, considering it solves many issues and also gives a nice perf boost.
>

Hi, I think hoping for an array subtype in Lua is probably going to
result in disappointment. The table as the sole data structure is a
defining feature of Lua; not only that, the semantics associated with
table iteration and nils, makes it impossible to introduce such a
subtype without break compatibility with existing programs. Combining
an array type with a singleton 'undefined' value may be an option, but
didn't Roberto say in one of his posts:

> Once 'empty' and 'undef' are values, you break all those properties.

> I think we cannot use a value to represent the absence of a value, no
> matter how many no-value values we add. It is a contradiction. Several
> languages followed this path, always with bad results.

So it seems that the idea of a singleton 'undefined' value is also not
acceptable.

Of course we could see a new Lua language definition in 6.0 that makes
a clean break from 5.x as Hisham suggested. But if I were asked to bet
on it I would probably say that an array subtype will not happen.

Regards
Dibyendu