lua-users home
lua-l archive

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

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.


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

Luis Carvalho (Kozure)
lua -e 'print(((""):gsub("(%u+%.)","")))'