Re: Proposal: Constant Tables (i.e. composed keys)

[Lars Doelle <lars.doelle@...>]

From: Dirk Laurie <dpl@sun.ac.za>

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