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