Re: [ANN] Lua 5.4.0 (work1) now available

[Sean Conner <sean@...>]

It was thus said that the Great albertmcchan once stated:
> 
> 
> On Mar 14, 2018, at 2:12 PM, Sean Conner <sean@conman.org> wrote:
> 
> > It was thus said that the Great albertmcchan once stated:
> >> 
> >> what is so bad about the old syntax x = nil ?
> >> 
> >> false were added in lua to "store" nil in table, there is no need for undef.
> >> 
> >> I am curious, is there an example where undef is truly needed ?
> > 
> >  Assume you have the following JSON:
> > 
> >    [ 1 , 2 , true , false , nil , "alpha" , "beta" ]
> > 
> >  Under the current (5.3) behavior, you can convert this to the following
> > Lua table:
> > 
> >    { 1 , 2 , true , false , nil , "alpha" , "beta" }
> > 
> > but the length is undefined, because the nil creates a hole.  If you use
> > false instead:
> > 
> >    { 1 , 2 , true , false , false , "alpha" , "beta" }
> > 
> > the length *is* defined, but it may not have the same semantic meaning. 
> > Now, with the proposed undef (which seems to be confusing a lot of people),
> > the Lua table:
> > 
> >    { 1 , 2 , true , false , nil , "alpha" , "beta" }
> > 
> > would have a defined length and semantically matches the original JSON.
> > 
> >  -spc
> > 
> > 
> 
> If you really want a table without holes, just use false for nil in table.
> Your example have BOTH false and nil, that meant you wanted the hole.

  As I said, that might create a semantic difference when converting from
JSON to Lua.  

  CBOR defines both "Null" and "Undefined".  "Null" is not defined, but is
presumed to have the same meaning as JSON's null, or Lua's nil, or NULL from
C or similar notations.  Here is what the spec for CBOR says about
"Undefined":

	3.8.  Undefined Values
	
	   In some CBOR-based protocols, the simple value (Section 2.3) of
	   Undefined might be used by an encoder as a substitute for a data item
	   with an encoding problem, in order to allow the rest of the enclosing
	   data items to be encoded without harm.

but otherwise, it leaves "Undefined" undefined.  Now, switching gears.

  A major complaint about Lua is that nil cannot be used in a sequence. 

	x = { 1 , 2 , nil , 4 , 5 }

is not a sequence (and what #x returns is undefined).  And it has
implications:

	function foo(...)
	  local x = { ... }
	  print(select("#",...)
	  dump("x",x)
	end

	foo(1,2,nil,4,5)
	5
	x =
	{
	  [1] = 1.000000,
	  [2] = 2.000000,
	  [4] = 4.000000,
	  [5] = 5.000000,
	}

There's also:

	function bar(...)
	  local x = table.pack(...)
	  print(select('#",...)
	  dump("x",x)
	end

	bar(1,2,nil,4,5)
	5
	x =
	{
	  [1] = 1.000000,
	  [2] = 2.000000,
	  [4] = 4.000000,
	  [5] = 5.000000,
	  n = 5.000000,
	}

  Not very elegant.  

> Yes, "new" syntax undef can fill holes, but it can also make holes.
> 
> All it does is shift the name for nil. Now, undef does the work of nil.

  Not really.  nil still means "no value", but it becomes possible (with
"undef") to store one in a sequence, such that:

	x = { nil , nil , nil , nil , nil }

is of length 5.  If you do:

	x[3] = undef

*THEN* you get a hole in the sequence.  undef is NOT a value, even though
the syntax makes it look like a value, because it's backwards compatible
with Lua 5.3. [2]

  -spc

[1]	http://cbor.io/

[2]	I don't necessarily agree with Roberto's reasoning here to prevent
	code breakage.  Any code using the bit operators of Lua 5.3 can't be
	used under Lua 5.2 and he seemed fine with that.  I'm not sure why
	he didn't do

		undef x[3]

	Why is 5.4 compatibility with 5.3 important, but not 5.3 to 5.2?