Re: Definition of a sequence

[Dirk Laurie <dirk.laurie@...>]

2015-06-05 11:33 GMT+02:00 Tim Hill <drtimhill@gmail.com>:
>
>> 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 no longer do. The __len metamethod has solved the problem.

> (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.)

Let me try again.

I am not interested in abstract notions of what property of a table should be
called "length", I am interested in the conditions under which I can use the
built-in '#' operator reliably so that I can utilize the standard table library.

I use tables as annotated lists. I.e. there are items in it numbered
1,2,3,4,...,#t,
none of them nil, and no items numbered #t+1,#t+1, etc. There are also items
in it with names like "title" and "note" and "source".

I would like to have an item named, say, 2015.0605. As it stands now,
I will need
to call it "2015.0605", otherwise maybe some implementation of Lua on the
Blackcurrant Tart computer will get confused when it tries to find #t
on my table.

I think that is an unnecessary restriction. A one-word change in the manual
can lift it.