Re: Possible bug with the length operator

[Eduardo Ochs <eduardoochs@...>]

On Fri, Apr 1, 2011 at 11:03 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> Maybe we could collectively have a friendly, instructive standard
>> answer ready?
>
> My standard answer (not sure whether it is instructive) is that there is
> no good *meaning* for #t when t has holes. What should be the results
> of the following expressions?
>
>  #{[1000] = 1}
>  #{1, nil, 3, 4, 5, 6}
>  #{1, 2, nil, 4}
>  #{[4] = 4, 1, 2}
>  #{1, 2, 3, nil, 4, nil, nil}
>  #{1, 2, 3; x = 4}
>  t = {1, 2, 3, 4}; t[4] = nil; print(#t)
>  t = {1, 2, 3};    t[4] = nil; print(#t)
>
> How useful would be these results?
>
>
> To simply solve the non-determinism problem, there are at least the
> following options:
>
> 1 - the number of numeric (integer?) keys
> 2 - the total number of keys
> 3 - the largest numeric (integer?) key
> 4 - the smallest integer key k such that all keys 1..k are present
>
> For a table without holes, all options are equal except 2. Otherwise,
> all options are (always?) different.
>
> All options solve the non-determinism of the current #t, but none solves
> the real problem of how to give the "length" of a list with holes. (2
> may fail even for tables without holes, if the list is mixed with other
> non-numeric keys.) Each will be useful in a few particular cases, but
> none is generic.
>
> So, a really cheap way to implement 1, 3 or 4 would be welcome, mostly
> to improve the documentation. But it should be really cheap, because
> it does not solve the real problem anyway. ("really cheap" means
> zero memory overhead for tables + zero overhead for table access +
> sublinear time for # + very small overhead for table updates + simple
> implementation.)
>
> -- Roberto

An idea: use "or" (and "is", and English). So:

  #{[1]=1,[2]=1,[4]=1,[8]=1,[16]=1,[32]=1,[64]=1,[128]=1}
                   is 2 or 4 or 8 or 16 or 32 or 64 or 128
  #{[1000] = 1}                    is 0 or 1000
  #{1, nil, 3, 4, 5, 6}            is 1 or 6
  #{1, 2, nil, 4}                  is 2 or 4
  #{[4]=4, 1, 2}                   is 2 or 4
  #{1, 2, 3, nil, 4, nil, nil}     is 3 or 5
  #{1, 2, 3, x=4}                  is 3
  #{1, 2, 3, [4]=4, [4]=nil}       is 3
  #{1, 2, 3, nil}                  is 3

Note that this proposal is related to the one in
<http://lua-users.org/lists/lua-l/2011-02/msg01467.html>. There I
defined "vlists" to cope with a certain recurring conceptual problem;
here I am proposing a simple way to deal - in English - with the
non-determinism of the definition of "#" in
<http://www.lua.org/manual/5.1/manual.html#2.5.5>. I think that the
use of an "or" in such contexts is sufficiently striking to make
people think about it and understand what is going on.

  Cheers,
    Eduardo Ochs
    eduardoochs@gmail.com
    http://angg.twu.net/