Browse thread
[Caml-list] unboxing of unary datatypes
-
Hal Daume III
- Nicolas Cannasse
- Fabrice Le Fessant
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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. Hi, 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