Implementing tables - advice wanted

[Andrew Lentvorski]

Joe Armstrong (AL/EAB) wrote:
>> -----Original Message-----
>> From: ke han [mailto:ke.han@REDACTED] 

>> 3 - I don't see much value in this new data type if the key 
>> must be only atoms or strings.  Too restrictive and would 
>> only server special cases.
> 
> In Lua keys strings and integers.
> 
> One design decision might be to limit the keys to say atoms, strings and integers
> In Lua tables contain two areas - a hash table and an array table. If Lua 
> can find some integer key N such that half the slots from 1 .. N are in use and at least
> one slot from N/2 to N are in use then it will put these items into an array
> Exceptions are put into a regular hash table.

What about terms like {atom1, atom2}?

What you want to avoid is the Perl problem where the only thing which 
could key a hash was a string (I think this has been fixed).  Suddenly, 
everybody was splitting and mangling strings to get around the fact that 
they really wanted more advanced keys on their hashes.

Basically, if it's immutable and you can create a hash for it, it should 
be usable as a key.  That's pretty much the Python philosophy.

Even if it's *not* immutable, but you can create a hash for it, Python 
will often let you dump it into a dict.

I liked your proposal for structs a lot where the "record" effectively 
carries around its own dictionary for runtime use.

>> programmer.  Smalltalk and Java have several good dictionary 
>> types but do not have special syntax for them.  This works 
>> out just fine.

I disagree.  Try building an assembler in Java.  Look at just how many 
characters you spend simply initializing the opcode hashes.

It's huge.  Even my beginning students ask: "Isn't there a better way?"

It's no wonder Java folks think XML is useful.

And don't get me started about the lack of an easy to use tuple in Java. 
  I use Vector<Object> way too much in Java.

-a