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

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

>> - 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).

Yea, but providing the arg. count is leaking the abstraction. If I am
to make an optional parameter in the middle of the arg. list, should I
account for the real arg. count or use an ipairs()-like iteration? In
other words, should I account for trailing nils? What if some other
function that my function wraps up is sensible about the arg. count as
well? I have to carry around arg. count everywhere. Whereas without
this leak, {...} would had been enough.

>
>> - 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.

Yes, I was wrong. There's no "unbounding", just re-bounding to a new
value, which can happen to be nil.

>
>> - 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).
>

I dig it. But then __index should not be called for the nil key to
make sure the rule is not broken.

>> - 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.
>

This I don't buy. How does it simplifies it? The few iterators that I
wrote don't get any more complex if they return a flag up front. I
don't think it's a matter of taste when the result is loss of
functionality (i.e. it's not natural to have a pseudo-index for
iterators like varargs(...), or sparse_array:values()).

>> - 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".
>

I'm getting there :)

But (I'm not letting this go you see) if I write a function that
supposedly works with the "array part" of a table, and not just with
an "array", then I must be careful not to use #t and only use ipairs()
instead. Or maybe I shouldn't care and always ask for a proper array?