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 MAA06029; Mon, 18 Aug 2003 12:04:19 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA13220; Mon, 18 Aug 2003 12:04:18 +0200 (MET DST) Date: Mon, 18 Aug 2003 12:04:18 +0200 From: Xavier Leroy To: Florian Douetteau Cc: Jacques Garrigue , caml-list@pauillac.inria.fr Subject: Re: [Caml-list] Obj.magic, Obj.t etc. Message-ID: <20030818120418.B12053@pauillac.inria.fr> References: <20030814105551S.garrigue@kurims.kyoto-u.ac.jp> <002401c3623d$22c3f2e0$0201a8c0@foorama> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <002401c3623d$22c3f2e0$0201a8c0@foorama>; from Florian.Douetteau@ens.fr on Thu, Aug 14, 2003 at 10:22:00AM +0200 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 val:01 abstr:01 amusing:01 subtyping:01 florian:01 douetteau:01 advocated:01 runtime:01 homogeneous:01 invalidated:01 unboxed:01 non-float:01 run-time:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue writes: > > 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 Yes, that's a amusing example, but it just confirms the party line that *any* function from module Obj is dangerous and must not be used if one has any hope of type safety. > From a subtyping point of view, this basically means that there cannot > be any "top" element in the ocaml type system. Florian Douetteau writes: > To be fully accurate, it only means that the current implementation > of the code generator would not support it directly. Right. More generally, I have long advocated the exploitation of properties of the static type system in optimizing data representations, runtime system operations, and code generation. The above is just an exploitation of the property of "classic" ML that an array is always homogeneous (all elements have the same principal type). A corollary is that if the type system changes significantly, some of these optimizations are invalidated. Introducing a "top" type is one of these significant changes. Quite frankly, I see zero practical uses of a "top" type, so why bother? > I don't know if the current runtime implementation makes other > assumptions of the same kind about the lack of subtyping; for > instance, the gc could avoid marking the content of an array > starting with an unboxed integer ? Same thing about list cells. No, these optimizations are not done because 1- non-float arrays have the same run-time tag as other data structures, e.g. tuples and records, and 2- an unboxed int can also represent a constant constructor from a sum or variant type. - Xavier Leroy ------------------- 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