lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


In message <c001e91951.wra1th@wra1th.plus.com> you wrote:

> In message <20100519142632.GC30640@inf.puc-rio.br> you wrote:
>
> > > My thinking was that if t[1] is not defined, then the array part of
> > > t is {} - I had believed that # should depend only on the array
> > > part of a table.
> >
> > What do you mean by "the array part of a table"?
>
> That a table x (if constructed) would be the array part of a table t if:
>
>   define n to be the greatest integer for which t has keys
>   1,2, ... ,n or zero if t has no such keys;
>   then x has keys 1,2, ... ,n and x[i] == t[i] has the value true for
>   i = 1,2, ... ,n or else x is {}.
>
> What I mean by "has keys" troubles me in the light of the fact
> that if x = { } and y = { nil } then x[1] == y[1] is true.
> Yet x has no keys, whereas y has 1 as a key. So there appears to
> be no way semantic way of testing "having the same keys" -
> one is appealing to what is happening "under the hood".
>
> Am I making sense? Perhaps I am just airing my own confusions about
> what is old news to others. In which case apologies for the noise.

Postscript. In view of the troubles with holes, one might prefer
to deal with arrays of non-nil values. So a table x is an Array (to
distinguish from any previous notion) if either it is {} or
there is a positive integer n such that x[i] is non-nil for
i = 1, ... ,n and is nil for all other keys. For such a table I
presume that #x = n. Then the Array-part of a table t is an Array x
for which (t[i] and x[i] and t[i] == x[i]) is true for all i = 1, ... ,n.

Seeing that nil is useful for denoting error conditions, and that it is
useful to distinguish errors, has any consideration been given to having
lots of different, possibly user-definable, nils? One might want a table
t to have its own nil, say nil_t, which would be the value returned
by t[k] if the key k is not defined for t. I am sure that many will
throw up their hands in horror at this prospect of complication,
but perhaps it deserves some thought?

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/