lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 04/01/17 10:04 PM, Gary V. Vaughan wrote:

On Jan 4, 2017, at 8:09 AM, Soni L. <fakedme@gmail.com> wrote:

On 04/01/17 12:06 PM, Gary V. Vaughan wrote:

On Jan 4, 2017, at 4:32 AM, Soni L. <fakedme@gmail.com> wrote:


On 04/01/17 02:24 AM, 聂威 wrote:
dear list,

I have noticed that `table.unpack(list [,i [, j]])` will NOT regards the `n` field in the `list` table,

I know I can write it like this:

```
table.unpack(list, 1, list.n)
```

but will it be a good idea to make it read `n` field in table.unpack?

thanks and happy new year!

ps:

table.pack in Lua 5.3 manual:

```


      |table.pack (···)|

Returns a new table with all parameters stored into keys 1, 2, etc. and with a field "|n|" with the total number of parameters. Note that the resulting table may not be a sequence.

```

Here's a better idea:

Why not make table.pack return a table, the value 1, and the total number of parameters?

That way, table.unpack(table.pack(f())) is equivalent to f().

But why? There is no practical reason to immediately unpack what was just packed. At some point you need to access the packed values.

Consider:

    local args, from, to = table.pack(...)
    -- or argsvalues = table.pack(table.pack(...))?
    -- or argstable = {table.pack(...)}?
    local r = {n=from}
    for i = from, to do
      r[i] = process(args[i])
    end

versus, IMHO clearer:

    local args = table.pack(...)
    local r = {n=args.n}
    for i = 1, args.n do
       r[i] = args[i]
    end

Cheers,
Gary


t, 1, n is more useful than t, t.n for functions that take a table, a start and an end.

process(table.pack(...)) vs local t = table.pack(...) process(t, 1, t.n)

Interesting. It would certainly allow for designing your APIs in a different style.


Would also be nicer if the standard table library were object-oriented:

table.sorter(function(a, b) return b < a end)(table.pack(...)) -- auto-sort args

  function table.sorter(comparator)
     return function(argu)
       table.sort(argu, comparator)
       return argu
     end
   end


Yeah, table.sort doesn't support start/end index. :/

But the others do:


table.concater(" | ")(table.pack(...)) -- auto-concat args
io.write(table.concater("\t")

   function table.concater(separator)
     return function(argu)
       return table.concat(argu, separator)
     end
   end


function table.concater(sep)
  return function(t, i, j)
    return table.concat(t, sep, i, j)
  end
end


(processtostring(table.pack(...))),"\n") -- print(...) implementation, where processtostring calls tostring on every element

   function processtostring(argu)
     local r = {}
     for i = 1, argu.n do
       r[i] = tostring(argu[i])
     end
     return r
   end


function processtostring(t, i, j)
  for k = i, j do
    t[k] = tostring(t[k])
  end
  return t
end

You might ask "why object-oriented table library?". Consider this:

In current Lua:

table.concat(t, 1, #t, " ") -- error
table.concat(tableandindices(), " ") -- doesn't do what you want (would error if it did) 

Some alternatives:

table.concat(" ", t, 1, #t) -- looks fine, yes?
table.concat(nil, t) -- NO IT DOESN'T D:

table.concater()(t) -- uses default, no `nil`
table.concater(" ")(t) -- concats with spaces
table.concater()(t, 1, #t) -- start/end index

local tabber = table.concater("\t") -- save it for later
function printstrings(...)
  io.write(tabber(table.pack(...)), '\n') -- use it
end

And, of course, table.pack would be the LITERAL opposite of table.unpack:

table.pack(1, 2, 3) --> {1, 2, 3}, 1, 3
table.unpack({1, 2, 3}, 1, 3) --> 1, 2, 3

table.unpack(table.pack(1, 2, 3)) --> 1, 2, 3
table.pack(table.unpack({1, 2, 3}, 1, 3) --> {1, 2, 3}, 1, 3
Every return value, when passed to the opposite function, produces, as its return values, the same values passed in as arguments. pack would be a "vararg to 3" function and unpack would be a "3 to varret" function. 


--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.






--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.