Re: [Caml-list] hash_variant anomalies

[Miles Egan <miles@caddr.com>]

On Tue, Jul 03, 2001 at 09:42:10AM +0200, Xavier Leroy wrote:
> 2- Owing to the Caml encoding of integers (integer N is represented by
> the bit pattern for 2N+1), when the manual says that constant
> constructors are numbered starting from 0, it really means that the
> constant constructors are represented by the representation of 0, the
> representation of 1, etc, that is, by 1, 3, etc.

Ok.  That makes sense.  I think this language is a bit confusing:

"""
the hash value for a variant constructor named, say, VConstr is
hash_value("VConstr").

The variant value `VConstr is represented by hash_value("VConstr"). The variant
value `VConstr(v) is represented by a block of size 2 and tag 0, with field
number 0 containing hash_value("VConstr") and field number 1 containing v.
"""

What wasn't clear to me is that both sentences are referring to polymorphic
variants, when they seem to be comparing the properties of normal variants and
polymorphic variants.  Chapter 2 of the manual uses the term "variant" to refer to
both kinds of variants, so when I see a sentence describing a variant "VConstr"
and a variant "`VConstr" I assume it's referring to both types.

I guess the upshot of all this is that it's much easier to map polymorphic
variants to C constants because there's no easy way to calculate the integer
value of a normal variant without knowing it's position in the variant
declaration.  The integer value of a polymorphic variant can be computed
directly from its name alone.

Overall I have to say writing ocaml-c interfaces is pretty easy.  Mapping long
lists of c enums and defines to ocaml variants seems to be one of the more
tedious tasks.

-- 
miles
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr