Re: tables holding nil

[Cosmin Apreutesei <cosmin.apreutesei@...>]

On Thu, Jul 23, 2009 at 02:25, Cosmin
Apreutesei<cosmin.apreutesei@gazolin.ro> wrote:
>> If nil is allowed as a table key, then next() would have to use some
>> other value for the beginning and end of a table.
>
> Actually, I never liked the fact that nil is used to signal the end of
> an iteration. Whenever I build an iterator that might return nil
> elements, I have to put a pseudo-index as the first return value of
> the iterator as a workaround.

To allow iterators to return nil as a value, the iterator protocol
could be generalized as
     do
       local f, s, var_1, ···, var_n = explist
       while true do
         local more, var_1, ···, var_n = f(s, var_1, ···, var_n)
         if not more then break end
         block
       end
     end

Should next() continue to be the iterator returned by pairs() (but who
says it shoud), its common usage scenario would be
  more,k,v=next(t)
  while more do
     ........
     more,k,v=next(t)
  end

This would allow constructing simple iterators for sparse arrays,
sets, or varargs, all of which can return nil as a valid value.