Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Hash clash in polymorphic variants
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Kuba Ober <ober.14@o...>
Subject: Re: [Caml-list] Hash clash in polymorphic variants
On Friday 11 January 2008, Jon Harrop wrote:
> On Friday 11 January 2008 13:30:29 Kuba Ober wrote:
> > Are those collisions of any real importance? I mean, do they break
> > anything? If all they do is imply linearly searching a list of a few
> > elements, for the colliding entry, then it's a non-issue?
> It would prevent code from compiling so it would be a complete
> show-stopper.

So what you're saying is that the implementation uses the hash with bucket 
size of 1? That's kinda poor decision, methinks.

Maybe perfect hashes should be used, computed at link time (and at runtime 
whenever a module is linked in). The pefect hashing function could probably 
implement some sort of a table, so that no real code would need to be
generated, just recomputing of decision tree table. Gperf code could be
adapted for that. The benefit is that there would be no collisions, the hashed
data structure would be very compact, and the cost to regenerate the hash is
amortized. Ideally, one would generate the actual perfect hashing function,
but this is currently only possible in bytecode, right? I mean, toplevel won't
run in native code? Or am I mistaken?