First-Class constraints and AddressHashTable

[Konstantin Popov]

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

if I may point it out, its name reads 'AddressHashTable', not
'HashTable'. Personally, if it's not clear what it means, I'd steer
clear ;-)

The problem is that I did not figure out (when the whole thing was
overhauled) that this thing is also used elsewhere. This exposes IMHO
the real problem - that everyone, starting from contrib' writers,
Mogul moguls, and moving on to everybody else using the Mozart's
external C interface is free to peek inside the implementation and
complain when it does change without their consent. E.g. the new
distribution subsystem shows the way to solve the issue: to clearly
define, and thus limit the imterface exposed by the emulator.

And yes, writing comments after others is not a honour duty. I guess I
actually did better than fixing comments - I added assertions that
would expose the problem right away. Don't ask me why [other] people
remove assertions (and in this particular case, as it looks like, -
for fixing some non-working/debug code!)..

And certainly yes, while the feeling of angriness at the deficiencies
of code and/or persons who wrote is understandable to me, I'd
recommend to watch the language - it's beneficial to be constrictive.

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

yet better idea is NOT to use the emulator internal services: not
mentioning the SE issues, these were also optimized, trust me, for
specific purposes.

> 
> > 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
> 
> _______________________________________________________________________________
> __
> mozart-hackers mailing list                           mozart-hackers at ps.uni-sb.
> de      
> http://www.mozart-oz.org/mailman/listinfo/mozart-hackers

Cheers,

 --- Kostja.