Re: Empty? No. Array? No. Has? Yes.

[Sean Conner <sean@...>]

It was thus said that the Great Coda Highland once stated:
> On Wed, Jul 3, 2013 at 11:44 AM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
> >> With my JSON library it is possible to write
> >>
> >>   getmetatable(db.null).__tojson = function () return "null" end
> >>
> >> and db.null would work for the JSON encoder as well.  And in the other
> >> direction you can just tell the decoder to use any arbitrary value for null.
> >
> > It should be clear that how to represent "null" in JSON is a problem
> > quite different from how to represent "null" in Lua.
> >
> > If we add a new value in Lua (call it null, empty, nothing, whatever)
> > to represent null in JSON, the problem with JSON is solved, because
> > we do not change JSON. This change is trivial to do, but only solves
> > the JSON problem.
> >
> > If we add a new value in Lua (call it null, empty, nothing, whatever)
> > to represent null in *Lua*, the problem is not solved. Now Lua has a new
> > value, and therefore we need yet another value to represent this new
> > Lua value. Adding new values will not solve the problem in Lua. Period.
> >
> > -- Roberto
> >
> 
> I'm afraid I don't understand the problem here. How is it that you'd
> need a new value to describe a "null" value? It seems to me that if
> it's permitted to be its own description, problem solved.

  Here's a JSON object:

	[ 1 , 2 , 3 , null , 5 , 6 , 7 ]

  While that does have a represntation in Lua:

	{ 1 , 2 , 3 , nil , 5 , 6 , 7 }

it doesn't have a defined length (depending on implementation of Lua and/or
the JSON parser, I can see it having a length of 3, 6 or 7).  

  -spc (Erm ... that reminds me, I need to figure out how to handle that
	with my JSON [1] parser ... )

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/json.lua