Re: Empty? No. Array? No. Has? Yes.

[Luis Carvalho <lexcarvalho@...>]

Jorge wrote:
>    What i'm trying to say is that in your business logic nil must not have
>    any extra meaning beyond what Lua gives it ("there is no data here").
>    And in that meaning, if I write a buble-sorting library i expect arrays
>    to be arrays, where every slot is data bound to be sorted. If i was
>    supposed to support a mythical "array with holes", i would have to copy
>    all the data to a proper array first! And if the nil actually get
>    somehow sorted, then it's not a nil, but proper data, that better have
>    an agreed upon meaning trough all the program and libraries... The
>    motivation for storing nils in arrays is to give them a meaning they do
>    not have in the language, and it will collide with someone else's use,
>    sooner or later.

That's right. Moreover, I interpret a nil in a dynamic fixed-length array or
in a fixed-key-set table as a missing value, similar to R's NA. For instance,
in R functions like "mean" and "sort" have arguments that change their
behavior with respect to NAs: they can be ignored, sorted to the front or to
the back.
 
Tim Hill wrote:
>    100% agree, which is why my original proposal was NOT to fiddle with nil
>    in any way; it was to add an 'empty' value which would just behave like a
>    normal value except only be equal to itself. Then your array would not
>    have holes, it could sort normally (assuming 'empty' had a distinguished
>    collating behavior) etc. And yes, these uses DO have a tendency to
>    collide, which is why I suggested some attempt at a standard or convention
>    was a good idea.

You could standardize nil in the same way you would "empty" in an array.

Cheers,
Luis

-- 
Computers are useless. They can only give you answers.
                -- Pablo Picasso

-- 
Luis Carvalho (Kozure)
lua -e 'print((("lexcarvalho@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'