First-Class constraints and AddressHashTable

[Raphael Collet]

Harmon Nine wrote:
> I’ve tracked down the problem to the “htAdd” member function of the 
> “AddressHashTable” class, in the file “platform/emulator/hashtbl.cc”.
(...)
> The problem is with the “else if” in the while loop.  If a program tries 
> to change the value that is stored under a hash key “k” (which is hashed 
> to the value “key” in the function) to “val”, as in handled by the “else 
> if”, this simply fails (i.e. nothing is actually done).

When I read Mozart's source code, I often feel like it was written by 
complete idiots.  Actually they are idiots because many of those guys 
simply never put the 5 lines of comments that may save hours to a poor 
programmer trying to read their code.

Obviously AddressHashTable was not designed to implement a mutable map.

> Is there a problem with changing the value stored under a key in an 
> AddressHashTable?

No.  The simplest solution IMO is to add a method htAddOverWrite(k,v) 
that explicitly overwrites an existing entry.  We already did that in a 
branch of Mozart's cvs.  I can put this fix in the devel version, if you 
want so.

> If so, perhaps I’ll use SGI’s “hashmap” extension to 
> the STL for the Reflect module.

Don't forget that the garbage collector relocates data.  So if your 
map's keys are references in the heap, make sure you rebuild the map at 
each garbage collection.

Cheers,
raph