RE: lua-5.1-alpha: length operator on tables (arrays) and nil values

["Bilyk, Alex" <ABilyk@...>]

I also find this a problem, at least for myself. We have all sorts of explanations why such is the behaviour of #, but It's just plain counterintuitive to say the least. If not going into reading the manual as to why such is the behavior, the results produced by the cases below make no sense whatsoever and seem totally random. This doesn't click well in my mind with the bulk of Lua, which I find rather simple and intuitive.

I think the problems stem from the fact that a vector and a hash under the hood are presented at language level as a single concept of a 'table'. It would be easier to implement and maintain, it seems, two separate language concepts of a vector and a hash, rather then doing all sorts of acrobatics in attempts to present them via a single language construct.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Michael Roth
Sent: Tuesday, September 13, 2005 2:58 PM
To: Lua list
Subject: lua-5.1-alpha: length operator on tables (arrays) and nil
values


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello list,

I have a question regarding the  new length operator.
The documentation of 5.1-alpha says:

    The length of a table t is defined to be any integer
    index n such that t[n] is not nil and t[n+1] is nil;
    moreover, if t[1] is nil, n may be zero.

    [...]

    If the array has "holes" (that is, nil values between
    other non-nil values), then #t may be any of the indices
    that precede a nil value [...]

This is a problem, because it could result to weird results:

    t = { 1, 2, 3, 4, 5, 6, 7, 8 }
    t[5] = nil
    t[8] = nil

    #t  ---> 7

But:

    t = { 1, 2, 3, 4, 5, 6, 7, 8 }
    t[4] = nil
    t[8] = nil

    #t  ---> 3

And, more weird:

    t = {}
    t[1] = 1
    t[4] = 4

    #t  ---> 1

    t[2] = nil
    t[3] = nil

    #t  ---> 4

So the problem arise, in 5.1-alpha there isn't a way to get the index of
the largest non nil value in an array. Even lua_objlen() doesn't help.

This will result in some more headache in vararg functions called with
nil arguments...

So, my question is: How to deal with this situation? How to use arrays
containing holes? How to handle nil arguments in vararg functions?

To me it looks like that in 5.1-alpha arrays are simple not able to
handle nil values. What's the rational behind this decision?


cu

Michael
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJ0thSIrOxc3jOmoRAq5HAJ9h36Vz0dDCApW14+QFVahw6hLMNgCfdkmF
D/+w0PPJKKwBxLuUoBJBXRA=
=9mrU
-----END PGP SIGNATURE-----