Re: Lua next version

[Cosmin Apreutesei <cosmin.apreutesei@...>]

On Wed, Jun 24, 2009 at 14:36, Luiz Henrique de
Figueiredo<lhf@tecgraf.puc-rio.br> wrote:
>> Given the persistent confusion about arrays vs. tables, and the scope
>> for really nasty hard-to-find bugs if people get it wrong, it might be
>> worth considering a 'strict mode' option (by default off, of course)
>> that cause #, table.remove/insert etc to *fail* if you give them a table
>> that's not an array. By fail, I mean throw an error to cause you
>> application to stop.
>
> How do you propose to do that? I mean, how can the Lua core detect that a
> table is not an array without traversing it completely?
>

That's easy, just flag the table on each modification and then just
read the flag, that shouldn't produce much overhead, and would even
help making some optimizations (like allocating the map part
differently from the array part, etc.).

This would settle the matter straight about what a table is and how it
behaves at any point at runtime, but more importantly, in the manual
(eg. more meaningful definitions for #).

This leads to a chain of changes:

1) make a subtype() built-in function to read that flag (it would give
you "array", "sparse array", "map", etc.).. let type() alone for
compatibility.
2) throw an error when applying # to any table that's not subtype
"array" -- very much needed for reliability of programs in general,
IMHO.
3) allow appending with a[] = x instead of a[#a + 1] = x, to allow change 2).

You might argue that these features are not core enough to worth
bloating the language with, especially since you can do them in plain
lua or C, but I can argue that the problems with that approach are
even bigger: 1) didactic (new users), 2) standardization, 3)
efficiency. A standard library of common abstractions would solve all
problems of course, but I is it possible to build it efficiently
(either in C or lua) on top of current infrastructure?