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

[Dirk Laurie <dirk.laurie@...>]

2016-07-07 9:08 GMT+02:00 steve donovan <steve.j.donovan@gmail.com>:
> On Thu, Jul 7, 2016 at 8:30 AM, Coda Highland <chighland@gmail.com> wrote:
>> The counterproposal being made is to use the existing language
>> features to define a type that has a specific set of behaviors for the
>> scenarios where those behaviors are explicitly desired without making
>> modifications that would affect the language more broadly.
>
> Exactly. Like the pack/unpack case.
>
> Personally I wear Dirk's "Lua works for me" T-shirt (if it weren't so
> damn cold in the mornings) and I look after a lot of Lua. The urge to
> keep nils in tables other than varargs does not happen to me. It would
> be cool if #t was O(1), however.

That T-shirt happens to be in the wash this morning ...

We've had several threads and I can't without re-reading everything
give credit where credit is due, but the following ideas for fixed-length
tables seem to be useful enough to keep in mind.

1. The __len metafield could contain an integer, not a function.
2. That could be used to flag the table as a fixed-length array
that may contain nils.
3. Supply __newindex metamethod if you want to treat an assignment
outside the range of a fixed-length table as an error.
4. This will automatically cause table.insert to be an error.
5. The semantics of table.insert could be revised so that in the case
of a fixed-length table, no assigment beyond __len is made, but an
error is signalled if the last element is not nil.
6. Automatic resizing of a fixed-length array could be replaced
by doing it only on request (e.g. a function table.resize).

This does not seem to be too large for a PowerPatch.