Re: lists with nil play nice for Lua 5.2

["David Burgess" <dburgess@...>]

I liked Diego's suggestion about table behaviour  changes being
controlled in a similar manner to weak keys and values.

For ME, I like Claim 1 and I do not want to support nils in tables.

I would like # to return the number of entries for contiguous arrays,
maxn for non-contiguous arrays
and return nil for tables with a hash part.

e.g.

> =#{1,2,3}
3

> =#{1,2;[5]=5} -- currently undefined
5

> =#{a=1,b=2}
nil

I could settle for also returning nil in the second case.
The idea is that if we cant supply a real value for # then return nil.

Re: the nils in tables, I think this can best be supported by userdata
structures.

db

Roberto wrote:
> I would like to make some claims...
>
> Claim 1: We lied: nils are not first-class values (because we cannot
> store them in talbes...).
>
> Claim 2: no magic will allow '#' to recognize nils at the "end" of
> a table. If we want lists with nils in the end, we not only need
> some 'n' field (that is, stored somewhere), but we also need some
> way to manipulate this field (t.n=t.n+1, table.setn, something like
> this). T[magic]=nil simply does not work.
>
> Claim 3: if we want lists with nils in the middle (holes), we better
> have lists with nils in the end. Too often we build lists adding
> elements one by one. To build a list with a nil in the middle, somewhere
> along the way it must have a nil in the end.
>
> So, changing the definition of '#' will not solve the problem of
> lists with nils.
>
> Lists with nils need a somewhat explicit notion of size. We can bury
> this 'n' deep inside Lua and create some magic operations to manipulate
> them, or we can store it in the clear. In the past we used the famous
> ".n" field, but there were all kinds of complains against it. Maybe
> we could store this size in t[0]? (At least it is a numeric key ;)
>
> -- Roberto
>