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

[Hisham <h@...>]

On 24 July 2016 at 23:48, Tim Hill <drtimhill@gmail.com> wrote:
>
>> On Jul 24, 2016, at 11:34 AM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>>
>> Of course any function can return nil among its returns, but maybe
>> that might be considered a bad practice.
>>
>> My point is that, if nil is representing the absence of a value, it
>> is weird not to have a third value but to have a fourth one. If nil
>> is representing something else, probably it shouldn't be (as pointed
>> out by others already).
>>
>> ("is weird" ~ "it might be considered weird”)
>
>
> It’s weird *only* if the values are a strict list. If the values are (conceptually) a tuple, then of course an intermediate may be nil. While it could be argued that tuples should be returned as tables, you have the same problem; you can’t put a nil mid-way (and, as others have noted, returning a tuple directly can be faster and has less memory churn).

Yes, that's what I meant. In a function, sometimes I'll return three
unrelated things and any one of them might be nil.

function get_bla_data()
   -- ...
   return size, parent, color
end

-- parent might be nil, no problem
local size, parent, color = get_bla_data()

So in essence, I end up returning a tuple because that's what
multiple-returns (conceptually) are, but the order is pretty
arbitrary. I just want to return three things and get these three
things on the other side. Sure, I could return them as a table with
named keys, but that would be cumbersome/heavier/slower and then we
wouldn't need multiple-returns (or table-packing results!) at all.

function get_bla_data()
   -- ...
   return { size = size, parent = parent, color = color }
end

local bla_data = get_bla_data()
local size, parent, color = bla_data.size, bla_data.parent, bla_data.color
-- boring!!

Shocking thought right after writing this: if Lua had some kind of
table auto-destructuring syntax, could it get rid at once of varargs,
multiple-returns and table-packing-unpacking altogether!?

Thought experiment: here's a brave new blue-sky, half-baked "Lua 6 -
now everything-is-tables even more" world

(1) As a preliminary, needed for the stuff below, # becomes a special
valid table key (note that # ~= "#").

* #t is redefined to return t[#] if this key is set, or the Lua 5.3
semantics of #t if it is not.
* pairs(t) always skips t[#]
* if t[#] is set, ipairs(t) traverses up to t[#]

(2) Multiple returns are now actually a table

   return x, y, z

becomes sugar for

   return { [1] = x, [2] = y, [3] = z, [#] = 3 }

(3.1) Function arguments and varargs are now actually a table

   function f(x, y, z)
     -- ...
   end

becomes sugar for

   function f(_ARG)
      local x, y, z = _ARG[1], _ARG[2], _ARG[3]
      -- ...
   end

(3.2) Explicit varargs become a destructuring construct for _ARG:

   function(x, y, ...)
      local t = { ... }
   end

becomes sugar for

   function f(_ARG)
      local x, y, z = _ARG[1], _ARG[2]
      local t = { [#] = _ARG[#] - 2, [1] = _ARG[3], --[[...]] }
   end

(4) Function calls auto-structure its arguments into a table:

   f(10, 20)

becomes sugar for

   f({[1] = 10, [2] = 20, [#] = 2})

(5.1) Returns of function calls in expression contexts
auto-destructure the return table:

   local x, y, z = f()

becomes sugar for

   local _t = f()
   local x, y, z = _t[1], _t[2], _t[3]

(5.2) Returns of function calls in table constructor contexts
auto-destructure the table, including the size:

   local t = { f() }

becomes sugar for

   local _t = f()
   local t = { [1] = _t[1], [2] = _t[2], [3] = _t[3], [#] = _t[#] }

(translation of { f(), g() } with reasonable semantics and the
equivalent for (5.1) are left as an exercise (I said it was
half-baked!) )

Results:

* All functions receive a single argument, a table (_ARG), and return
a single argument, a table (which you never get to touch).

* No more table.pack() or select(), just use _ARG explicitly.

* No more table.unpack(), just do { f() }, which does the right thing

* { ... } also does the right thing

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

-- Hisham