Re: Definition of table.insert

[Dirk Laurie <dpl@...>]

On Tue, Jan 11, 2011 at 09:05:12AM +0200, Henning Diedrich wrote:
> You also stress by that, that table must not be seen as one type, but two
> in one. I would suggest that's also too complicated. A table should not
> behave differently depending on how it has been treated before. Simple
> as that in my eyes.
> 
Undefined behavour is just that: undefined.

Could you narrow down your objection as a disagreement with one of the
following propositions?

1. Lua has one and exactly one sophisticated data structure: a table,
    which is a map from a set of keys to a set of values.  Both these
    sets are subsets of the set of first-class values.
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.
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.
4. Certain functions such as ipairs, #, table.insert and table.remove 
    are designed to make life easier for us when the numeric keys in
    our table form just such a continuous block.
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.
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.

Dirk