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 KAA18641; Thu, 14 Aug 2003 10:34:54 +0200 (MET DST) 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 KAA17307 for ; Thu, 14 Aug 2003 10:34:53 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h7E8Ypf24420 for ; Thu, 14 Aug 2003 10:34:52 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2/3.7W) with ESMTP id RAA21441; Thu, 14 Aug 2003 17:34:44 +0900 (JST) To: Florian.Douetteau@ens.fr Cc: caml-list@pauillac.inria.fr Subject: Re: [Caml-list] Obj.magic, Obj.t etc. In-Reply-To: <002401c3623d$22c3f2e0$0201a8c0@foorama> References: <20030814105551S.garrigue@kurims.kyoto-u.ac.jp> <002401c3623d$22c3f2e0$0201a8c0@foorama> 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: <20030814173444D.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 14 Aug 2003 17:34:44 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; jacques:01 caml-list:01 florian:01 douetteau:01 val:01 abstr:01 subtyping:01 unboxed:01 compile-time:01 neutralize:01 incompatible:01 arrays:01 ocaml:01 garrigue:01 supported:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: "Florian Douetteau" > > As an interesting aside, I've discovered recently that even Obj.repr > > is dangerous: > > > > # Obj.repr;; > > - : 'a -> Obj.t = > > # let arr = Array.create 1 (Obj.repr 1.0);; > > val arr : Obj.t array = [||] > > # arr.(0) <- Obj.repr 1;; > > Segmentation fault > > > > >From a subtyping point of view, this basically means that there cannot > > be any "top" element in the ocaml type system. > > To be fully accurate, it only means that the current implementation of the > code generator would > not support it directly. > If subtyping was to be supported, an unboxed float array would be created > iff > its the compile-time type "float array" (it would be created boxed if typed > "Top array") . Not so simple: it would also mean that all polymorphic functions on arrays would create only boxed arrays, since their compile time type is not float array. As a result, the representation of float arrays would not be uniform, requiring a check before access, which would probably neutralize any performance advantage of having a special representation. Sure, this is an implementation problem. But not a simple one. The only simple solution would be to have a special type for float arrays, just like strings... highly incompatible. 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