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