Table metaphor & implementation wish list

[Henning Diedrich <hd2010@...>]

Hi Frank and Dirk,

just as a question, and this is just academic, ok, no offense to anybody but for the slim chance of finding a nugget by coincidence, as anybody will concede could always be the case. Anybody bored by the topic, please forgive the vanity:

On 1/10/11 6:45 PM, Frank Siebenlist wrote (thread 'Definition of table.insert'):

I believe that if we manage to separate the map and array metaphors of a lua-table, then we can live with nil for the array-personality.

At the current state of the discussion in "Definition of table.insert" do you think we could possibly clarify the metaphor for tables, not as it is but as it could be, 'should' be maybe

• based on the spirit it was intended as - and what that spirit may be,
• but shorter than e.g. Dirk's characterization below, not as a matter of wording, but contents
  
• and without newbie pitfalls
• and without undue penalties to performance or implementation complexity

But /one/ metaphor, unbroken by constraints: What's the "ideal table metaphor and implementation"?

Just off the top of my hat, stuff like:

1 - a table is easy to understand and use and can be use as anything, a map, a list, an array
2 - all operators & functions working predictably the same, no matter the contents and history of the table

--> constructors with nil in it don't break anything
--> constructors with trailing nils don't break anything
--> it doesn't matter whether it's kicked in with 0 or 1 (??)
--> it can have negative keys

3 - stuff that does not make sense / could rarely be useful / is most likely unintended* -> throws an error

4 - Functions that should always work are:
a. count = number of elements?
b. size = highest numeric element (R!?)
c. maxkey = highest key when sorted alphanumerically?
d. maxvalue = highest value when sorted alphanumerically?
...

This is really just to illustrate the question, not my full answer. I would like to find a very simple definition actually, brief and clear.

After that, one could talk about implementation, or concrete, coherent proposals for changes to implementation maybe.

It should be kept in mind that the table is the Swiss Army Knife of Lua and as far as I saw is used for all the stuff going on 'underneath', too, which made a good deal of Lua's elegance. So respect is in order. But may be not too much.

Thanks,
Henning

*) yes don't preguess, but don't invite errors either.


On 1/11/11 9:30 AM, Dirk Laurie wrote (thread Definition of table.insert):

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    

--
*Henning Diedrich*
CEO

Eonblast Corporation
h...@eonblast.com
+1.404.418.5002
www.eonblast.com


This email contains confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is prohibited.