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

[Cosmin Apreutesei <cosmin.apreutesei@...>]

> 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.
- the nil value is transferable (by assignment), along with the
responsibility of unbounding a variable --> double duty.
- 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.
- 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?
- 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.