ocaml to c variant hashes

ocaml to c variant hashes

[Chris Hecker]

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

Re: ocaml to c variant hashes

[Jacques Garrigue]

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

This is the right way. You can consider this as "the definition" of
how to hash a variant. Basically it only assumes that all ocaml
architectures support 31-bit integers efficiently. As I do not see any
risk of this becoming false, and as 32-bit architectures are still
around for a while, there is no compelling reason to change it.

Only if 32-bit architectures disappear, and ocaml support 63-bit
integers everywhere, there could be a discussion of changing this
hashing function, but I suppose this would be publicized enough.

As to whether you should use var2def.ml, or use the C hash_variant
function, this is basically a question of efficiency: I prefer
preprocessing because runtime cost is null, and you can put the values
in static tables. You can also use switch, but beware of code size
with gcc. You can see lablgtk for how to have conversion functions
that are both efficient and small. By the way, you can ignore
copyright issues on var2def.ml/var2conv.ml: anyway you have to use
them with ocaml, so feel free to modify and distribute under any name.

        Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>