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: -- (:)
From: Nicolas Cannasse <warplayer@f...>
Subject: Re: [Caml-list] unboxing of unary datatypes
> Hi all,
> 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.


What you might need here are shadow types.
You can define in your ML source file:

type foo = float
let mfoo f f' = f *. f' (* or better let mfoo = ( *. ) *)

and in your interface ( MLI file ) :

type foo
val mfoo : foo -> foo -> foo

then, other modules trying to work with your foo will have to use your set
of operators because they won't know what exactly is "foo".

> Can someone explain this to me?  Why doesn't the compiler optimize out the
> constructor?

Because they don't have the same C raw representation.
There is one more indirection when you use a constructor.
If you want to interface OCaml with C, you have to be sure that the compiler
won't try to optimize things in an incompatible way ( that goes for all
compilers I think... )

Nicolas Cannasse

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