Re: A tricky way to determine Lua version (updated)

If that code is scrappy, then why the Lua documentation fully specifies the syntax of table constructors using keys that can be arbitrary expressions? For now the syntax is fully documented, since long, but it has NEVER worked reliably, never been portable, and extremely sensitive to the implementation of tables, that has changed multiple times.

It's caused by the fact that the existing implementation, while trying to optimize the storage by segregating an array part and an hashed part, has NEVER specified its own invariants. And not determining the assignment order is still a flaw, even if the table has only a single hashed part for everything.

This is a clear incoherence between what is fully documented (the syntax of table constructors can have arbitrary key _expression_ with arbitrary non-nil datatype) but the implementation has NEVER supported it correctly.

Le jeu. 23 juil. 2020 à 22:46, Andrew Starks <andrew@starksfam.org> a écrit :

> On Jul 23, 2020, at 12:56, Philippe Verdy <verdyp@gmail.com> wrote:
>
> Beside obviously funny code like {1, [1]=2}, the issue is more serious with this code, not created just for fun by hackers:
>
> { [k(1)] = v(1), [k(2)] = v(2) }

I can’t tell your tone through email but this seems like a lot of arm waving about the crappy code that programmers can write. If someone showed me this code in production, without tons of comments or proof of prior sanity checks, I would throw up into my mouth a little. It’s just crappy code.

Lua is a scripting language, but it’s unique because it’s so tiny and simple. It has well documented undefined behavior where other languages give you guarantees about order and errors when it thinks you’re doing something stupid.

It’s fine. Just because you can do breathtakingly dumb things with it, doesn’t mean you can’t write correct code and be productive with it.

You can keep waving your arms around but there isn’t any evidence of this being a real problem.

-Andrew Starks