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

[Elias Hogstvedt <eliashogstvedt@...>]

> I’ve written several hundred thousand lines of Lua code over the past 10 years or so, and in my experience tables with holes are very rare. In those few rare cases I’ve had them, it has been no problem to have an extra ’n’ field. In fact, I have a wrapper module for arrays (similar to what has been mentioned earlier in this thread) but I think I’ve only used it a couple of times over the years.

It's more or less the same for me. If you know the details it's very unlikely you'll run into the problem. So as I've said before this is more for the people who are relatively new to Lua. (which might be an unpopular bias I guess).

> + 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)?

I'm not sure about this either. if a list is constructed as [1,nil,3] then index 2 and 4,5,6,7,... will be nil. The length will be 3 but what happens to index 4 if you do list[5] = 5 ? maybe it should just become nil and the length becomes 5? As I was writing this I wasn't sure but nil seems to make the most sense in Lua.

> - 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?

> - 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.

> - 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.

On Sat, Jan 20, 2018 at 11:57 AM, Petri Häkkinen <petrih3@gmail.com> wrote:

My two cents...

I think this discussion is again about tables with holes and the # operator which have been discussed a lot in the past.

I’ve written several hundred thousand lines of Lua code over the past 10 years or so, and in my experience tables with holes are very rare. In those few rare cases I’ve had them, it has been no problem to have an extra ’n’ field. In fact, I have a wrapper module for arrays (similar to what has been mentioned earlier in this thread) but I think I’ve only used it a couple of times over the years.

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)?

- new type => more complex language and implementation

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

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

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

Best regards,

Petri