Re: Quest: real world "Lua array with holes" usage

[Dirk Laurie <dirk.laurie@...>]

2016-07-26 0:19 GMT+02:00 Hisham <h@hisham.hm>:

> (3.1) Function arguments and varargs are now actually a table
> (3.2) Explicit varargs become a destructuring construct for _ARG:
> (4) Function calls auto-structure its arguments into a table:
> (5.1) Returns of function calls in expression contexts
> auto-destructure the return table:
> (5.2) Returns of function calls in table constructor contexts
> auto-destructure the table, including the size:

> Of course, the implementation would optimize away these implicit
> tables at compile-time. After all, the vast majority of functions
> won't refer to _ARG explicitly and the return-values table is
> essentially conceptual. Only functions using _ARG would pay for a
> table, etc.
>
> I hope you all enjoyed reading this as much as I enjoyed writing it,
> and now have fun shooting it down by pointing out all the obvious
> flaws that I evidently haven't spent any time pondering about! :-D

Nothing I enjoy more :-)

1. It seems not to pass Occam's razor to say that conceptually there
is a table _ARG but it is optimized away if not needed. Rather say
that a reference to a nonexistent _ARG causes it to be implicitly
constructed.

2. In that case _ARG is revealed to be just an incompatible cousin
of 'arg' as in Lua 5.0, and the question arises: why incompatible?
Why can't the vararg still start at 1 and other parameters exploit
the negative numbers? Thus making _ARG just a local version
of the current 'arg' for commandline parameters?

3. But wait, why did Lua 5.1 discard 'arg' in favour of 'select'?
There must have been good reasons. Have they become invalid
in the meantime?

4. Alternatively, _ARG[k] could just be sugar for debug.getlocal(1,k),
then you don't need any new concept at all. Occam would approve.

5. In fact, one can do that already:

local _ARG = setmetatable({},{__index =
  function(tbl,k) local _,v =debug.getlocal(2,k) return v end})