Re: pairs and ipairs

[rzvxa <rzvxa@...>]

Hello guys,

Sorry to jump in.

I agree with the fact that keeping Lua simple is good for the longevity of the project. There are more robust scripting languages for getting a feature-complete runtime, Lua has been created as simple as possible and I don't know if they intended this or just wanted to get it done as fast as possible but it makes a good fit for embedded and for a long time in games(Now the industry is shifting towards use of C# for this need).

But I think there is room for a more feature-complete language that transpiles to Lua and brings additional features to the language such as types, pattern matching, easier lambda definition without the full function syntax, and other things that can bring value to a more complex project running on Lua.

I've seen Roblox is doing something with the `Luau` for their ecosystem, But I would love to see a typed Lua that can target every Lua interpreter/compiler out there. Transpiling it can be both easier and can bring more users for the project if it can keep the backward compatibility with Vanilla Lua(like typescript does with _javascript_).

This way every production code used in Nginx, Cloudflare, every editor plugin for Neovim, and every game code for World of Warcraft have the possibility of gradually adopting this language if done right(as there are some transpilers out there but execution matters more than the idea itself).

And please write it in Rust, Writing it in the language itself can be exciting, well who doesn't want to keep their code cycling into itself forever and ever? It's really easy to set up a LSP with Rust and the resulting compiler would be Blazing Fast™.

Kind Regards,

Ali Rezvani

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, October 22nd, 2023 at 2:18 PM, Kalbermatter.nl <rolf.kalbermatter@kalbermatter.nl> wrote:

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