Re: A proposal for the confusing pseudo table ≈ array concept

[Dibyendu Majumdar <mobile@...>]

Hi,

On 20 January 2018 at 10:57, Petri Häkkinen <petrih3@gmail.com> wrote:
> Some pros/cons of having a separate array type in my opinion:
>
> + possibly more efficient implementation
>
> + it would be possible to have out of bounds checking, but unclear if they should be errors or behave more like tables (return nil on read and extend the array on write)?
>

In Ravi, I have implemented two array subtypes of the table type -
integer[] and number[]. So it is possible to implement array sub
types.
For these two types the implementation is indeed more efficient as the
values are stored as normal integer/double arrays rather than Lua
Value arrays.

The main issue from a language perspective is how to declare such
arrays. In Ravi you can write:

   local x = @integer[] { 1, 2, 3 }

   or

   local x: integer[] = { 1, 2, 3 }

   or

   local x = table.intarray(3)
   x[1] = 1
   x[2] = 2
   x[3] = 3

The first two methods create dynamic arrays - which grow if you set a
value at 1+last index.
The third method creates a 'fixed size' array.

Length of array is maintained internally.

All C api and Lua api functions on tables work seemlessly on arrays -
except that if you try to assign the wrong type of value an error is
raised. You also cannot use arrays as metatables or override __index,
__newindex or __len metamethods on arrays.

Array indices start at 1 just like tables, but there is a [0] index
that is accessible if you explicitly code it (for efficiency of
implementation).

The arrays subtypes have the benefit that the GC does not scan the
array values as these are known to be primitive types - so that is a
great saving when you need large arrays.

I have thought about having a generic array type as well - i.e. a
table constrained such that no hash values can be inserted, and length
of the array is not determined using the normal methods. However have
not yet implemented this. Setting the length will probably have to be
done either via the constructor or an explicit setlength() function,
so that it is possible for the array to have nil values without this
affecting the length of the array.

> - new type => more complex language and implementation
>

The complexity is internal - at user level mostly it can be hidden
except for the support needed to create array objects. For Lua I guess
using [] instead of {} constructor syntax might be an option.

> - more complex C bindings, most C modules should work with both tables and arrays for conveniency?
>

Again mostly it can be made transparent. In Ravi all api calls that
expect tables, also handle arrays.

> - converting between tables and arrays, probably not very common, but would still have a cost when needed
>

Should not be necessary as arrays just appear as restricted tables
(restricted in that invalid operations are not permitted).

> - arrays would not have hash part, so can’t add extra info to them in named fields (pretty common thing in Lua I think)
>

In Ravi, you cannot assign values to the hash part when working with
arrays, but internally the hash part is still present and is used to
reference 'parent' arrays when you create slices. Being able to create
slices of arrays that reference part of the existing array is very
useful.

I think that from a technical standpoint it is possible to have an
array subtype without breaking existing code. So the obstacle is more
philosophical. A defining characteristic of Lua is the single
aggregate table type - so I am sure there will not be much appetite to
change this.

Regards
Dibyendu