lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

And where does it contradict what I said ? I just said that ipairs() does not enumerate only the array part, because of course integer keys in the sequence can also be in the hashed part (given the fact that the arry part is only populated by constructors, and all the rest is populated by assignments, the array part is not evolving, there's no strategy to move items from the hash part to the array part. So items of the sequences may be alternatively in each part.

All this shows that the "optimization" make in tables (using an array part) was half-done, never really finalized.

As well the order of evaluation becomes completely random. This old optimization is unsafe, in fact Lua could even live without this array part and have used only the hashed part. This would have not done a major difference. But at least it would have simplified the specification and allowed to develop a correct behavior and semantics of table constructors, with a well defined order of evaluations of _expression_ (for keys and values) and the assignment of keys in the table.

The current implementation of tables is simply unsafe. And even the hashed part is incorrectly optimized. That's very strange given that tables are a fundamental feature of Lua: there are tables almost everywhere (except arrays for upvalues, the stack of calls and the array of local variables), accessing/indexing tables is extremely frequent (including for lookup of metamethods in metatables).

Le sam. 25 juil. 2020 à 03:14, Sean Conner <> a écrit :
It was thus said that the Great Philippe Verdy once stated:
> I tend to disagree. The "sequence" meaning does not imply that ipairs()
> enumerates only the array part.

  You never bothered to even check the source code, did you?  Because if you
did, you would see that the implementation returns an iterator that starts
with the number 1, and incrments the index on each pass until lua_geti()
returns LUA_TNIL.