lua-users home
lua-l archive

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




Often it is simply premature optimization. In this case it seems to shave off one not needed variable in the Lua script for a pairs loop at the cost of ambiguous definitions, extra complexity in the Lua source code and potentially even extra runtime in the loop execution.
Sounds to me like anything but a real optimization.

Rolf Kalbermatter

On 22 Oct 2023, at 12:33, Claudio Grondi <claudio.grondi@freenet.de> wrote:




To keep a scripting programming language clean and small in interpreter size it is a good idea to refrain from adding features which could be very easily achieved by one line of code.

It is sure possible that you come up with a non-ambiguous definition goal what kpairs() should do, but why not define such function if needed in custom script code?

I can't see any benefit from adding kpairs() or similar special cases of iteration over table items to Lua.

Claudio

On 10/22/23 11:51, Hans van der Meer wrote:
Thanks for all your replies.

I am well aware of the fact that the proposal of a kpairs(0 has some limitations and pitfalls.

Thus for example a key "3" entered in the table as that string belongs to the hash part of the table and should therefore appears in a native kpairs() traversal. That obviates the problem with tonumber(key) in my post. (hmmm, better perhaps testing type(key) instead of tonumber).

Holes in the array part I do not see as a problem. Everything in the array part (in a sequence or not) should in my proposal be left out of a kpairs(0 traversal.

Limiting kpairs() to the keys in the hash storage of the table exclusively and excluding everything in the array part, does seem a usable definition in my view.

yours sincerely
dr. Hans van der Meer


On 22 Oct 2023, at 11:29, Tom Sutcliffe <tomsci@me.com> wrote:

I think the edge cases make it difficult to usefully define. What should something like this do?

{ [1] = "a", [2] = "b", [4] = "d", a = true }

This table is not a sequence, because of the 'hole' between 2 and 4, but ipairs is well-defined to return 1 and 2, so should kpairs include 4? Should all integers be excluded even if they aren't currently part of what ipairs would return? Should kpairs be the exact logical opposite of what ipairs returns, or can there be keys which neither would return? Could one actually implement any definition in a way that didn't require an extra O(N) time and/or space operation?

More concretely, only the caller really knows the intended semantics of any given table. The definition of sequence currently used by Lua carefully carves out one specific type (and only for one specific operation, the len operator) while imposing as few restrictions on any other usage as possible, and there is no definition of what constitutes a "record" key. Intuitively we might think it's obvious, but only because we have a specific usage of table in mind, and there would need to be a definition which both accounts for corner cases, and is sufficiently general to be of use to others whose usage of table might be ever so slightly different.

As another example, the code you suggested would include string keys convertible to integers, which would not be part of the sequence, which just highlights the fact that there are a lot of subtleties in attempting to come up with a meaningful definition :)

Cheers,

Tom

On 22 Oct 2023, at 09:52, Hans van der Meer <havdmeer@ziggo.nl> wrote:

This question might have come up earlier, but I have not seen it. Thus I dare to ask.

With ipairs() a table is walked through the array sequence in the table.
With pairs() all elements are visited while traversing the table, the sequence as well as the records.
However, sometimes I need to visit the record keys only, leaving the elements of the sequence out.
Of course I can do:
for k,v in pairs(t) do
if not tonumber(k) then ... end
end

But why isn't there a kpairs() for the record keys? I think it would make some programs easier, especially where the relevant pairs() function is passed to another function.

If I am wrong I will gladly hear it.

yours sincerely
dr. Hans van der Meer