Re: tables holding nil: another way to look at the question itself

[Jerome Vuarand <jerome.vuarand@...>]

2009/7/25 Cosmin Apreutesei <cosmin.apreutesei@gmail.com>:
>> When a question makes no sense, does it matter what the answer is?
>> (What is the sound of one hand clapping?)  A language designer can
>> rule it illegal to even ask the question, e.g. Scheme forbids asking
>> (car '()).  Or, an arbitrary answer can be defined because it is
>> convenient, e.g. in Lisp (car nil) is nil.
>
> If I can have nil in function argument/return value, store it in a
> variable (as transferable information, not as meaning "unbounded"),
> then I need it in table keys and table values, and in return value of
> iterators. Any interpretation of nil (as an end marker, etc.) makes
> its usage as a value non-transparent. At least the iterator thingie
> really itches me as I can't find a workaround for it.
>
> ---- boring rant follows ----
>
> As I'm learning out, the nil value/type has many responsibilities in
> Lua, unlike say, SQL where it's meaning is more tight (convenient- the
> context is much tighter too). The lua manual is quite careful not to
> constrain your understanding with any bounds or vision upon the
> concepts it defines (I dig it), so you're left alone to build your own
> mental models. As a novice, all this liberty makes me uneasy, so
> (mistake #1) I try to infer semantics from behavior (like in reverse
> engineering) -- which involves the nil value a lot. So questions pop
> out about the nature of the nil and the things around it, like:
>
> - why is there a difference between a list of nil arguments and no
> argument? --> nil is acting like any other value here.

That's an extra feature provided for convenience. Just like you can
see tables as infinite key-value pairs, you can see argument list as
infinite list of values, defaulting to nil. As a convenience you can
get the number of values that was actually passed to a function call,
but you can still access all elements of the argument list (just call
select(42, ...) for example).

> - the nil value is transferable (by assignment), along with the
> responsibility of unbounding a variable --> double duty.

Like any other assignment, assigning to nil is unbinding the variable
from its previous value, and binding it to its new value. No special
case here. In "a=print; a={}", the second assignment is unbinding 'a'
from print and it's binding it to a table.

> - nil responds to type() --> a hint that nil is a value, if so,
> shouldn't it be allowed as a table key? table keys are said to hold
> any lua value.

nil is a normal value, just like 42, true, false and "Hello World!".
The authors decided that the value associated to nil in a table should
always be nil, that key-value pair is read-only. Sometimes you have to
accept exceptions to the rule. That exception has motivations
(previously discussed on that list).

> - the for protocol uses nil to break the loop --> nil can't be used as
> the first return value of an iterator. what does that saying?

It simplifies the iterator protocol a lot to mark the end of iteration
with a special value rather than another mechanism. Whatever the
special value (currently it's nil), if it's a regular value, it
implies you cannot iterate over it. As with most questions of this
thread it's mostly a matter of taste.

> - can arrays hold the nil? those "defined" by ipairs() can't, but what
> if I provide the bounds myself? lua hints me that indexing integer
> keys is not a hash operation and seems to be all I need to know.. so
> is ipairs() really needed? I mean apart from being bad PR making some
> people believe that arrays are crippled in Lua, along with the darn #
> operator.

The array is not such a fundamental data structure in Lua, as opposed
to C for example. I think all these pseudo-problems around them
quickly vanish once you start programming in Lua "à la Lua".