[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Empty? No. Array? No. Has? Yes.
- From: Jay Carlson <nop@...>
- Date: Thu, 4 Jul 2013 10:41:24 -0400
On Jul 3, 2013, at 2:44 PM, Roberto Ierusalimschy 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.
Yes. I consider it a feature of XML-RPC values that there is no way of representing "null". I'm pretty sure this is because Dave Winer's pet language didn't really have them, not because it was a matter of deep principle. Treatment of null in the other languages targeted by XML-RPC was all over the place anyway, especially in aggregate types.
XML-RPC does have both true and false. At the time I wrote the XML-RPC binding, Lua had no false. I used a distinguished table to represent it. Has false been a success? I'm not certain.
> 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.
Well, you could add an immutable boxed value type, to signify a value was quoted; this would nest. But heading down any route to undefined() is a good way for people to make comedy videos about your language--although you need an architected quiet NaN to really bring it home.
I'd be willing to contemplate a uniform void value, but only if it were true-ish. We already went through nil->false, and I'm bored. I want new, interesting bugs rather than boring old NullPointerExceptions.