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

[Elias Hogstvedt <eliashogstvedt@...>]

I don’t get it. Where’s the ambiguity in e. g. { 1, 2, 3, type = ”int16” } ?

I would say it's ambiguous because I'm not sure if this is "safe" to do. I've personally never done this and would put a new table inside the table to hold the numbers. If this has no side effects then it's more or less a shortcut for {array = {1, 2, 3}, type = "int16"} ?

I could also say it's ambiguous because I don't know if it's a hash map or an array ( { 1, 2, 3, foo = ”bar } ) but then I think it's more on me for expecting Lua to have an array type in the first place.

On Sun, Jan 21, 2018 at 9:43 AM, Petri Häkkinen <petrih3@gmail.com> wrote:

On 20 Jan 2018, at 13.41, Elias Hogstvedt <eliashogstvedt@gmail.com> wrote:

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

If you're pushing a list you'd do lua_newlist(L) instead of lua_newtable(L). Wouldn't the rest of the code be the same assuming you're pushing values onto the table in a sequential order?

List != array. In computer science a list is usually a data structure with fast insert and remove ops but no indexing. I prefer the term ’array’.

I’m assuming there would be a separate data structure inside Lua VM for arrays. To get the benefits of fast array access in C, there should be new APIs for getting/setting array values. If not, supporting arrays in existing Lua C API functions would slow down the current implementation (you’d have to do a branch to array/table routines).

”Know your data types” is the key to fast code with languages that have static typing.

> - new type => more complex language and implementation

My hunch is that it would be a simpler implementation as you would no longer assume tables can also be arrays under some circumstances. I haven't really looked all that much at the Lua internals though.

Please add an efficient new array type to Lua VM and C API and report back if the new version is less complex than the current one :)

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

This also is a useful feature of Lua I think but adding named fields onto a sequential table is a bit ambigious in the first place. You'd have to make a table and put the array inside of it as you'd have to do with all the other types in lua.

I don’t get it. Where’s the ambiguity in e. g. { 1, 2, 3, type = ”int16” } ?

Cheers,

Petri