Re: Second class nil? Strong and weak nils in tables?

[Miles Bader <miles@...>]

Miles Bader <miles@gnu.org> writes:
>> That's exactly my point. That code is the clear and natural way to use
>> {...}, but it also breaks whenever any of the args in ... is nil.
>
> No it doesn't (I tried it)...

I take this back -- I tried some more test cases, and it _sometimes_
works (with nils), but sometimes doesn't.  Specifically, in runs into the
weird behavior in Lua with respect to "#t".

So the main issue is keeping track of the number of arguments, you can't
just use #{...}.

For the case of immediate argument processing, it seems to me that
select is OK -- it's not as pretty as {...}, but it's probably more
efficient.

For the case where you want to bundle up the args and pass them to
another function for processing, I guess you've got to pass in the
number of arguments explicitly, or record them in the "arg table"
({...}) using a non-integer key.

Luckily that sort of thing can be encapsulated in handy functions... :-)
E.g.:

   # handy function
   function argvec(...)
     local args = {...}
     args.num = select ('#', ...)
     return args
   end

Then:

   function bar (...)
      local args = argvec(...)
      for i = 1, args.num do
         print (tostring(i).."\t"..tostring(args[i]))
      end
   end

seems pretty nice  :-)

[FWIW I don't really like the "nil value means delete" behavior of Lua
either; I wish Lua had an explicit table delete operator, and treated
nil as a normal value.  So I'd support adding a new table type that had
these properties.  OTOH, I'd also like a bunch of other little changes
(e.g. more flexible behavior to allow natural use of 0-based arrays),
and I guess it's unlikely most of them will ever end up in the official
language ... :-]

-Miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde