Holes

[Mark Hamburg <mark@...>]

Here is another potential solution to the "holes" problem:

1. Define a new value type HOLE or NIL or NULL or whatever. It doesn't really matter what one calls it because it's purely an implementation detail as we'll see below. Values of this type will only appear in the value fields of tables.

2. When reading a value from a table, if the value is equal to HOLE then read it as nil. This would be true even with rawget.

3. When storing a nil value to a table, if the table is specially marked -- e.g., an appropriate __mode value is set in the metatable (though that makes it hard to use the feature during table creation) -- then store HOLE. rawset would bypass this and store nil and would be what one needed to use to really remove values. (One variant would always do this during table construction under the theory that if you mention a value, you must actually care about it.)

4. The definition of #t remains unchanged. It does not view HOLES as being equivalent to nil.

A table marked in this way would support arrays with holes.

Perhaps just as interestingly, it also allows works nicely with __index metamethods. For example, it eases caching of function results that may include nil and it provides support for overriding values with nil in __index table chains.

The downsides include:

* Another values for LUAT_TYPE.
* Some extra logic when setting values in tables.
* And the big one... logic executed every time we read from a table. It's simple logic, but Lua tends to involve a lot of table reads.

So, I'm not convinced, but I think I like it better than the various redefinition proposals for #t and it also helps with __index constructions. I just don't know whether the overhead that would apply everywhere is worth the improvements in the cases where one wants holes support.

Mark