English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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 (03:34)
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 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