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 KAA27113; Thu, 5 Feb 2004 10:18:58 +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 KAA27236 for ; Thu, 5 Feb 2004 10:18:56 +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 i159Itv05038 for ; Thu, 5 Feb 2004 10:18:55 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id SAA14889; Thu, 5 Feb 2004 18:18:45 +0900 (JST) To: Damien.Pous@ens-lyon.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] functors and objects In-Reply-To: <20040205095512.62ef577d.Damien.Pous@ens-lyon.fr> References: <20040203190635.6cc61ff0.Damien.Pous@ens-lyon.fr> <20040204115745J.garrigue@kurims.kyoto-u.ac.jp> <20040205095512.62ef577d.Damien.Pous@ens-lyon.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: <20040205181845V.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 05 Feb 2004 18:18:45 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 functors:01 jacques:01 damien:01 damien:01 ens-lyon:01 soundness:01 covariant:01 unsound:01 soundness:01 checker:01 ocamlc:01 coupling:01 functorial:01 jacques:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Damien > > This isn't a problem of soundness. > > There is just no such thing as a "partially abstract" object type. > there is no such thing... > ...in the type system or in the compiler ? > > Sorry for mixing variants and objects again, > but I have got the feeling that since the example I posted with variants > works, the first example with objects could/should work : > It seems quite natural and reasonable. So why should it be rejected... Because instanciation/specialization only works for values, not for types. This is reasonable enough: once you have defined a type, you may use it both in covariant and contravariant positions, so allowing to specialize it would be unsound. (So, yes, in the long run this is a soundness problem.) The solution you describe with polymorphic variants use values, so specialization works as expected. > I don't really see what can prevent the compiler to do it. > It looks like an additional check in the type checker, > and almost nothing in the compiler > (that's just a feeling, I never looked at ocamlc sources...) Have a look if you have lots of free time :-) > > But as shown above, you can easily simulate it by coupling an abstract > > type with a coercion to an object type. > still curious : are such "coercion identity functions" eliminated by the > compiler ? Unfortunately, no. In general, functorial code (or object-oriented code) is much less optimized than a first order style. But it's not going to be very expensive either: just a few more jumps. 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