From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA18505; Tue, 14 Jan 2003 11:53:50 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA18541 for ; Tue, 14 Jan 2003 11:53:49 +0100 (MET) Received: from lachesis.inria.fr (lachesis.inria.fr [128.93.52.5]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h0EArar20857; Tue, 14 Jan 2003 11:53:36 +0100 (MET) Received: (from lefessan@localhost) by lachesis.inria.fr (8.12.5/8.12.5/Submit) id h0E9vM3O030357; Tue, 14 Jan 2003 10:57:22 +0100 From: Fabrice Le Fessant MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15907.57089.759815.660410@lachesis.inria.fr> Date: Tue, 14 Jan 2003 10:57:21 +0100 To: Hal Daume III Cc: Caml Mailing List Subject: Re: [Caml-list] unboxing of unary datatypes References: X-Mailer: VM 7.07 under Emacs 21.2.1 Reply-To: fabrice@lefessant.net Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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