The Undefined Country (was Re: Quest: real world "Lua array with holes" usage)

[Sean Conner <sean@...>]

It was thus said that the Great Roberto Ierusalimschy once stated:
> > I agree with Jorge. Also, sometimes when returning multiple things,
> > one of these things might be nil, so it's not only the error situation
> > that produces a nil value upon return, although it is of course the
> > most common. So, unfortunately just changing the policy from
> > nil-on-error to false-on-error still wouldn't allow us to just forget
> > about table.pack().
> 
> 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).

  Javascript has an "undefined" state, in addition to a "null" state. 
Perhaps Lua should have one as well.  To me, "nil" means "the absence of a
value" while "undef" means "this never had a value to begin with".

  Proposal:  undef.  It works just like nil does now, but "nil" (the new nil
behavior) is that it *is* allowed in sequences.  

	t = {}
	x = t.one	-- x is "undef"
	local zork	-- zork is "undef"
	t = { 1 , 2 , nil , 4 }
	y = #t		-- 4, because there are four items in t
	z = t[5]	-- z is "undef", falls outside sequence

	function foo(...)
	  local args = table.pack(...) -- no 'n' field to worry about
	  local a,b,c,d,e = table.unpack(t)
	  -- a is 1
	  -- b is 2
	  -- c is nil
	  -- d is 4
	  -- e is undef

	  if e then
	    print(e)
	  elseif e == nil then
	    print("e is nil")
	  elseif e == undef then
	    print("e never had a chance")
	  end
	end

  It seems, to me, to solve all the current issues Lua has with arrays.

  -spc (There's probably stuff I'm missing though ... )