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
[Caml-list] unboxing of unary datatypes
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-01-14 (18:38)
From: Christophe Raffalli <Christophe.Raffalli@u...>
Subject: Re: [Caml-list] unboxing of unary datatypes
Fabrice Le Fessant wrote:
>> I originally had a very calculation intensive program which used a data
>> type which looked like:
>> > type foo = Foo of float
>> I could just have easily used floats, but I wanted to ensure that I didn't
>> do anything stupid (like try to multiply a foo by a float), so I did this
>> boxing so the type-checker would help me out.
> In ocaml, there are no overloaded operations, not automatic
> conversions to integers, so that if you don't need to do that at
> all. The type system will always force you to use the operations on
> floats, or to convert them to foo before multiplying them by foo. 
>> But based on some non-scientific tests, it seems that this isn't the case,
>> and that the original foo type is actually represented using a
>> pointer-to-float.
>> I cannot imagine why this is the case (coming from a Haskell world, there
>> is a difference there between these two types due to laziness, but since
>> ocaml is strict, I figured this wouldn't be the case).
> If you want to keep the interface with C simple, you need an
> easy/efficient way to move ocaml values between caml functions and C
> functions. This is done by specifying the internal representation of
> ocaml values so that C functions know how to manipulate them. If you
> let the compiler optimize the representation of values, C functions
> won't be able to access ocaml values anymore (well, it will be more
> complicated, since you need to attach by some way a description of the
> representation of each value passed to a C function...).
> Of course, it could be done by some annotation, telling the compiler
> that the value will never be passed to a C function. But this would
> introduce useless complexity into the language.

Or let the compiler produce a C header describing the representation
of the data type, when it is optimized !

It would be nice if Data type with one unary constructor and many 
constant constructors could be optimized by using the fact that pointer
are always even (and non zero), so we can use the zero and/or the odd 
numbers to represent the constant

This would optimize a lot the 'a option type.

> - Fabrice
> -------------------
> To unsubscribe, mail Archives:
> Bug reports: FAQ:
> Beginner's list:

Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature