Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: checker@d6.com
Cc: caml-list@inria.fr
Subject: Re: ocaml to c variant hashes
Date: Wed, 01 Nov 2000 09:44:35 +0900	[thread overview]
Message-ID: <20001101094435H.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Sun, 29 Oct 2000 19:13:08 -0800" <4.3.2.7.2.20001029184954.00a8e3b0@shell16.ba.best.com>

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>



      reply	other threads:[~2000-11-02 17:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-30  3:13 Chris Hecker
2000-11-01  0:44 ` Jacques Garrigue [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001101094435H.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox