Re: Definition of a sequence

[Tim Hill <drtimhill@...>]

> On Jun 4, 2015, at 12:09 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 
> 2015-06-04 20:56 GMT+02:00 Tim Hill <drtimhill@gmail.com>:
> 
>> I see no reason why this should change. The support for 64-bit integers
>> doesn't change the concept, which is to disallow non-integral positive keys
>> in a sequence. The definition deals with values (integral vs non-integral)
>> not their representation (integer or integral float).
> 
> The point is that the definition not only disallows non-integral positive
> keys in a sequence, it makes the length operator non-deterministic
> the moment you have any positive non-integer key in your table,
> even though that key will never be referenced by any table library
> routine, and is not taken into account by the algorithm that calculates
> length. This is not an implementation detail, since length must be
> an integer.
> 

The length operator is *already* non-deterministic on anything that is not a sequence as a consequence of holes, as I have pointed out a number of times. The reference makes it quite clear; if the table is a sequence, the length operator is deterministic. If not, you cannot rely on it’s value nor on the behavior of the table library functions that expect sequences. What the various algorithms actually do when presented with a non-sequence is neither here not there; they are all “undefined results” insofar as the reference manual is concerned.

Case 1:
x = { “a”, “b”, “c”, “d” }
x[2] = nil
print(#x)

Case 2:
x = { “a”, “b”, “c”, “d” }
x[2.5] = “e”
print(#x)

In both cases, #x is undefined. I don’t particularly like case 1, but if you accept case 1 (as you have argued for in the past) I don’t see why case 2 deserves any different treatment.

(Length being an integer is unimportant. The “length” of case 2 could arguably be 5, which is an integer, even though the table has non integral numeric keys. Length is really misnamed, as what is being discussed in the cardinality of the table.)

—Tim