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 LAA29928; Wed, 13 Nov 2002 11:09:05 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA29922 for ; Wed, 13 Nov 2002 11:09:04 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id gADA8w122907 for ; Wed, 13 Nov 2002 11:08:59 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id TAA19781; Wed, 13 Nov 2002 19:08:42 +0900 (JST) To: malc@pulsesoft.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Records typing In-Reply-To: References: <20021113101131D.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021113190842B.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 13 Nov 2002 19:08:42 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: malc > > # module M = struct type t = float and r = {f:t} end;; > > # module M' = struct type t = float type r = {f : t} end;; > > > > In the first case, the record is represented as an array of a pointer > > to a boxed float, while in the second case it is represented as an > > array of an unboxed float. Since the data representation is different, > > these two signatures are not equivalent. I was afraid there would be > > no direct way to express the first case, but actually you can. > > What exactly triggered the switch from boxed to unboxed repersentation? > I mean, this is completely unobvious and can have severe performance > degradation, so description of cases when this might happen could be > useful. This the use of "and". In mutually recursive type definitions, other types are not "known" during the definition, and as a result their representation cannot be used for optimization. I think this is true for all ocaml releases, but it is specified nowhere, and could be wrong. Since you're not going to write the first defintion anyway, this shouldn't be a real problem. The real problem is that when you use a signature like sig type t type r = {f:t} end in a functor, then this signature cannot be instanciated by the unboxed version of r when t = float. And there is no way to solve it short of inlining functors. Cheers, Jacques Garrigue ------------------- 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