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 JAA15856; Tue, 19 Aug 2003 09:33:56 +0200 (MET DST) 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 JAA10263; Tue, 19 Aug 2003 09:33:55 +0200 (MET DST) 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 h7J7XrT09141; Tue, 19 Aug 2003 09:33:54 +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 QAA17026; Tue, 19 Aug 2003 16:33:51 +0900 (JST) To: xavier.leroy@inria.fr Cc: caml-list@pauillac.inria.fr Subject: Re: [Caml-list] Obj.magic, Obj.t etc. In-Reply-To: <20030818120418.B12053@pauillac.inria.fr> References: <20030814105551S.garrigue@kurims.kyoto-u.ac.jp> <002401c3623d$22c3f2e0$0201a8c0@foorama> <20030818120418.B12053@pauillac.inria.fr> 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: <20030819163351T.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 19 Aug 2003 16:33:51 +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 advocated:01 runtime:01 homogeneous:01 invalidated:01 convincing:01 caml:01 garrigue:01 objects:02 classic:03 obj:03 optimizing:03 argument:03 data:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Xavier Leroy > 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? Well not exactly zero: here is one example (the mail is by me, but I was answering a precise question) http://caml.inria.fr/archives/200307/msg00064.html Of course you can say: but we have objects for that, why bother? And it's probably right. Another reason is that it would allow to make both covariant-only and contravariant-only variables generalizable in non-values. Not so useful but any bit of polymorphism is good. So I would agree that there is no compelling need for such a feature, but not that there is zero practical uses. Also, the opposite argument would be more convincing if there were more examples showing that having a top type is bad for performance. To me the current situation is more like: not worth changing the implementation for it, but when designing from scratch this may be a valid choice. If you're ready to work in a world of homegeneous representations (i.e. no type-specialized representations). 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