Re: [Caml-list] unboxing of unary datatypes

[Fabrice Le Fessant <fabrice@lefessant.net>]

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

- Fabrice
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners