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