Re: new "empty" value/type in Lua?

[Tim Hill <drtimhill@...>]

On Jun 28, 2013, at 7:30 AM, Andrew Starks <andrew.starks@trms.com> wrote:

> I think that Tim's point is not that there is not a workable solution.
> It is that there are many workable solutions and since there is no
> clear one way to solve the problem, it is likely to cause a mess
> when/if there are libraries solving it in different ways.
> 
> Do I have that premise correctly stated?

Exactly. Everyone posts "look .. here's how you can do it" which is missing the point. I *know* how to do it, as I've repeatedly stated, in a dozen different ways (my preference is like yours, to use a light userdata wrapping a C NULL pointer btw).

My argument was:
(a) I see this as a useful generic language feature, that while lightweight is also light to implement and understand.
(b) It cleans up one of the side-cases of Lua, the odd behavior of Lua arrays when faced with nil values.

> If you long for a wider scope, then you're unlikely to be satisfied.
> As demonstrated by the previous posts, there usually isn't a whole lot
> of support behind adding new "things" to the language, especially when
> they're "policy" things.

Agreed, and 99 times out of 100 I'm on the side of "avoid feature bloat at all costs". But frankly some of the arguments used here seem zealous to say the least, and boil down to "Lua is perfect, any odd behaviors are by design and should stay odd". I really hope Lua isn't becoming a religion, rigidly set in stone because the "chosen ones" defend the holy language against the evil of change.

I *really* like Lua; it is, to my mind, the cleanest scripting language out there, by a WIDE margin. But i's not perfect; I was merely suggesting one area that is less elegant than other areas and a possible way to improve it.

> That is, there are many mechanisms in the language to accomplish
> exactly what you want. You want a policy, which is not really what Lua
> has traditionally been about.

Well it's a language level feature, which doesn't necessarily imply "policy", just a defined behavior that can be used in a number of different circumstances. The "spirit" of Lua, to my mind, is one of providing as much functionality and as little policy in as compact a language as possible, with as few surprises and enough sugar to make it familiar to those coming from other environments.

Regarding the "I see very little use for it" argument. I've now been involved in three MAJOR projects using Lua in a significant or key role (we are talking a LOT of Lua code and a LOT of C libraries here). In each case we have hit against real issues with interfacing between C and Lua where the lack of an "empty" feature has caused us to create workarounds of various types. And of course we've worked around them. But it left me thinking hard about how much simpler this would be if I had an "empty" value in the language and a few extra APIs like "lua_isempty()".

However, as you state, there is essentially zero chance of this happening, Thanks for your input, good discussion. As I stated as the start, I was expecting to be attacked, I think it's a pity no-one engaged beyond "hey look .. I know a workaround!" and "how dare you suggest we meddle with perfection!".

It would be amusing to speculate how people would react if Lua had always had "empty" and I posted a suggestion that it should be removed as being unnecessary, since there were obviously so many workarounds. :)

--Tim