Re: Possible bug with the length operator

[Roberto Ierusalimschy <roberto@...>]

> 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