From: Dirk Laurie On Sat, Aug 13, 2011 at 02:27:51PM +0200, Lars Doelle wrote: >> the concept of the central and only composed data type in LUA >> clearly lacking. >You mean, like all those other posters clamoring for something >that Perl or Python or Ruby or Smalltalk etc has, that something >you happen to want is not in Lua. And you seem to think that >by using an opprobrious term like "lacking" you will gain support. >Please understand this: Lua is a compromise between providing >powerful features and keeping the language small. The authors >are not so stupid as to have provided a "clearly lacking" table >type for seventeen years, nor so ignorant as not to know how >this is implemented in some other languages. On the contrary, >they have given careful thought to what features are desirable >in Lua, and have decided that Lua does not need internalized >constant tables. Dirk, cool down, I'm all on your side and i fully share your view. I'm interested in LUA only because what you say above, is true. My proposal is /NOT/ about featurism, i have carefully evaluated LUA, and i do not have a pet language (beside LUA perhaps) to push here. No, Dirk, please reread my original post. It is all about tables and hashing. The problem is rather to use a composed key. How would you do that in LUA? This is what i talk about, and the concept of tables is clear lacking here, if you like it or not. The problem is as follows: Normal hash tables are defined over a hash function and and equality, so that one can use /any/ data as a key. Not so in LUA, though hash-tables are the central and only structure. What the authors did where to define one such hash-function and equality for all LUA-data guaranteeing that the key remains unchanged. With tables treated as objects this leaves nothing but the objects name (i.e. pointer). Thus composed keys are not possible, though being flexible with what the key is, is NOT a limitiation of hash tables themselves but of their particular implementation in LUA. I'm not going to argue that one does need composed keys. One does. IMHO, the problem is not if LUA's table design is lacking, but rather how to cope with situation, either in user or system space. When adding something like a __hash and __equal method, one could well achive a likely result, but beside this might come out inefficient and complicate, my proposal goes into another direction. The very idea is to /construct/ tables that cannot be modified, thus guaranteeing to be unchanged and such being a good behaved key. Second, these tables are kept /unique/ like strings, allowing to use their object name (pointer) as it was done ever before. Dirk, seriously, i'm not proposing constant tables because it simply came into my mind as a "feature", but i'm rather interested to make tables become able to use composed keys. Now my proposal was perhaps to concrete as it suggest a paricular implementation, but it is a possible and relativ straight forward solution. -lars