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

[Luis Carvalho <lexcarvalho@...>]

Dirk Laurie wrote:

<snip>

> If I am allowed to, as far as the "empty" question is concerned,
> I can extract:
> 
>    Andrew thinks:
>       - nil makes a fantastic "empty" sentinel value;
>       - one should emphasize and increase the usefulness of nil's
>         role as "empty," for which it is a natural fit.
> 
> The main thrust of Andrew's post deals with the concept of deleting
> a value. That, I think, deserves a thread of its own.

It might. Let me just offer again the case of NA vs NULL in R, where two
different values serve the two purposes in our discussion: missing value (NA)
and deletion (NULL). I much prefer the lack of distinction in Lua as it
greatly simplifies the language.


Tim Hill wrote:

<snip>

>    Not really, I floated the idea that *some* agreed-upon mechanism *might*
>    be useful. I also suggested one (actually two) possible solutions; others
>    have made other suggestions that are equally valid.
>    To address the well-known idioms:
>    -- Using empty tables. Works will within a single Lua state, is more
>    awkward across Lua states as marshaling is needed and the table needs to
>    be manufactured in a "safe" haven such as the Registry, and then made
>    available via an API (and if you are doing all this, you might as well
>    fall back on my light userdata, which is less complex and faster).
>    -- Switch from arrays to manually managed tables of integer keys (or
>    similar), using "n" or some-such meta-managed state to track which
>    "elements" of the pseudo-array are empty. This is fine until you start to
>    wrap higher-level abstractions and want to do things like getter/setting
>    semantics on one of the empty elements, though nil can now do this job if
>    you are careful not to need nil for things like the "nil+error" Lua
>    convention for error handling. There is also of course some performance
>    overhead.

You seem to carry some sort of prejudice against the two other solutions,
trying to make them worse in light of your solution. To me, that's what makes
this discussion "tired and frustrating": you pretty much ignore or understate
other people's points and replies for the other two solutions, and does not
offer new arguments for the "empty" value. It's not much of a discussion; it's
more like a reiteration of your points, where the pros are highlighted and the
cons are dismissed. I'm probably missing something here, but I'm failing to
see the need of such a big change for such a simple (initial) problem.

To try and balance your points above, let me offer some other points:

- A blessed "empty" value would bring more complexity to the language. It
  seems like an innocent addition, but it carries a series of problems as
  you said earlier when comparing to R's NA vs NULL. In my opinion, the
  simplicity of the two other solutions seem to outweight the "empty" value
  solution.

- The only problem with nil, as far as arrays go, is its inability to mark the
  end of the array. This could be easily solved by agreeing on a field "n"
  that codes for the length. That's it, and it's already offered by
  table.pack as a way to handle nils. The array module, along with its
  metamethods, are simply facilities to make handling arrays easier; for
  example, there's no need for an __ipairs, since you can just loop with for
  i=1, t.n do. If you don't want the performance overhead, don't use the
  metamethods. Moreover, note that arrays with "n" field are sparse and have
  storage gains when compared to "full" arrays with "empty" entries.

Also, could you give some examples of what can go wrong when you want to use
"higher-level abstractions" and getter/setter semantics but need to be careful
not to need nil for nil+error? I don't see how that can be an issue when using
arrays as indexing (getting and setting) works as expected.

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+%.)","")))'