ocaml to c variant hashes

[Chris Hecker <checker@d6.com>]

Hi, I'm looking at the lablGL stuff, and came across a utility that computes the ocaml hash value for a given variant name.  The var2def.ml file in the package preprocesses a variables file and outputs a C header with the appropriate hash values.  The ml file contains a function, hash_variant	that does this hash, but that function is copied from the source code to the compiler.  This doesn't seem like a very robust way to do this, since the internal hash function could change at any time (in fact, the comment in the code says hash_variant is from ctype.ml, but it's now in btype.ml).

What's the right way to do this?  I can think of 3 ways:

1.  Like var2def.ml, and just hope the internal hash function doesn't change.

2.  Do it at runtime, by calling a function on the C side with a string and the variant.  That's slow and lame.

3.  Do it with camlp4.  This seems like the right way to do it because it's synced to the compiler version (I assume).  Is that true?

Are there better ways?  It seems like this is important if we're going to mix ocaml and C a lot.

Hmm...I just looked around a bit more, and the c interface docs talk about mlvalues.h's hash_variant, but I look in the source and hash.c's hash_variant is yet another copy of the same function.  Is there some way to make it call the btypes.ml hash_variant to avoid potential versioning bugs?

Given mlvalues.h's hash_variant, I suppose the correct way to do this is to call hash_variant at runtime?  Unfortunately, that means you can't have a switch statement with the values predefined when you compile your C version...

Also, the documentation for the hash_variant function in the html says that VConstr is hash_value("VConstr") and `VConstr is also hash_value("VConstr"), not hash_value("`VConstr") as you'd expect.  Is that true?

Chris