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

The initial project used some project-specific stuff that very domain specific (I cannot be more detailed, as this is commercially a bit sensitive). As the second project began, we looked at experience gained and realized we would need a similar (again domain-specific) concept that was similar to "empty" (it wasn't called that in the projects).

So we created the generic "empty" and back-ported it to the first project, which simplified several algorithms and ended with a much, much cleaner division of labor between C and Lua code.

The only APIs were two small C functions exposed to Lua:

x = getEMPTY()

b = isEMPTY(x)

getEMPTY() returned, you guessed it, the empty value, while isEMPTY tested for it. We also, purely by convention, store an EMPTY value in the global EMPTY.

Armed with this simple bit of code, a lot of Lua code got very much more "well duh!" type code, which I really liked. One thing we ended up with was a very clean transport format for heterogenous data that could move rapidly between Lua and C code (and elsewhere) with very low impedance between the Lua representation and the C/etc format.

I think the concept is capable of abuse in a couple of ways:

1. Confusion between nil and empty. This is clearly an area that needs to be carefully addressed. We handled it by making it clear that empty was just another normal value (for example, it evaluates to true in a boolean context).

2. Potential memory "leaks" if empty is used instead of nil. If someone doesn't "get" it, then they may use empty instead of nil to try to remove elements from a table, resulting in stuck items that are never reclaimed. This probably speaks to the name "empty" not being the best. otoh in the hands of a bad developer, ANY feature can be mis-used.

3. The "infinite" recurse problem. At Roberto pointed out, if you add "empty", one day someone comes along and says "ok, we used empty and all the other types, can we now have a type that is different from all the other types AND empty?".

Anyway, it's pretty much been voted down, which is fine, though i'm not sure I agree with some of the reasons stated.

--Tim

On Jun 30, 2013, at 1:12 AM, Jerome Vuarand <jerome.vuarand@gmail.com> wrote:

So, in these three MAJOR projects, did you extend Lua to have that "empty"
value? Given the relatively small size of Lua compared to any project that can
be qualified as MAJOR in capitals, there was no reason not to.

Did you implement the "empty" value in the same way for the three projects?
Did the concept (and eventually the implementation) apply equally well to the
three projects?

What are the few extra APIs that you had to define?

Did you initially abuse the concept to later realize it was useful in some
cases, but not that much in others?