Re: Definition of table.insert

[Axel Kittenberger <axkibe@...>]

> Undefined behavour is just that: undefined.

I differ, there are different "notions" of undefined. Luas # operator
is undefined in some cases in the sense of "multiple different results
allowed", the set of values allowed to return is well defined . On
contrary in C-terms "undefined" can mean "anything happening".
int a = 0;
void b() {a+=1;}
void c() (a=10;}
printf("%d\n", b() + c());

This is invalid code, undefined doesn't meean a may be 11 or 10
depending on which side of + gets executed first, it might be anything
up until segfault.

> 2. nil is not a first-class value and may therefore not be either
>    a key or a value.  Constructions like
>        if t[a]==nil ...
>        t[b]=nil
>    are nothing else than translations of statements like
>        "If t does not contain the key a ..."
>        "Remove b from the set of keys of t"
>    into Lua syntax.

Agree for tables. But in some cases nil is just a little bit more than absent.
select('#', 3, 4, nil, nil) ... here the nils matter.

> 3. The keys 1,2,3,...,n occur particularly often, and for our convenience,
>    a table constructor is provided that implicitly assigns those keys
>    so that we need only specify values.  A nil value given to that
>    constructor means: don't associate anything with that key just yet.

yup. at least when ignoring performance differences.

> 5. If you wish to use those functions, you should not use any numeric
>    keys outside the block, and also not allow any key properly inside
>    the block to be removed.

Well all positive integers should be continous. Negative and fractions
dont hurt.

> 6. Lua does not actually check that you have been law-abiding when you
>    do use these functions, but (except ipairs and to some extent #)
>    the result is undefined and you should not rely on any property
>    that in a particular implementation they have been observed to
>    possess.

Yes. But thats what the non-professonal coder gets caught so easily.
They suppose "if it works once, it will work always", and except the
table operations, I don't see a place in Lua outside from
C-interfacing where this fails. (Only exception are declaring weak
tables, here the GC can be some surprise for people who take some
issue of weak tables wrong.). In that regard undefined behaviour is
unlucky.

I repeat, my suggestion to have "List{}" as a default (builtin?)
"object" in the sense of a metatable to a table which actually defines
#/insert/remove and either errors() on losing the continous integer
keys,or loses its List status in sense of removing itself as
metatable.

Or in other words, tables keep to be the basic Lua building block, but
Lists is a default construct that builds on tables and makes
insert/remove/# operations easy.