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 CAA25220; Thu, 15 Nov 2001 02:06:40 +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 CAA25470 for ; Thu, 15 Nov 2001 02:06:30 +0100 (MET) Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fAF16NL29418 for ; Thu, 15 Nov 2001 02:06:28 +0100 (MET) Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17]) by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id KAA04337; Thu, 15 Nov 2001 10:06:17 +0900 To: william.newman@airmail.net Cc: caml-list@inria.fr Subject: Re: [Caml-list] difficulties narrowing OO types In-Reply-To: <20011114111708.A14071@rootless> References: <20011114111708.A14071@rootless> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011115100557Y.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 15 Nov 2001 10:05:57 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: William Harold Newman > OCaml seems generally reluctant to narrow OO types. OCaml is reluctant to do anything unsafe. > E.g., dynamically casting from a base class to a subclass is > unsupported (though I've seen the hack to work around this in Jason > Hickey's online introduction). No surprise, this is unsafe. Work arounds are available, but they may all fail at runtime. The technical reason for not having it as a construct in the language is that checking casts for parametric classes is much harder than for classes without parameters. > And as far as I can tell, it's > impossible for a method on a subclass to guarantee that it returns a > narrower type than the method on the base class. That's actually a quite different problem. Having a method in a subclass return a narrower type is type-safe, and is allowed by OCaml subtyping rules. Unfortunately, OCaml inheritance rules does not allow it. [Snipped lots of goods reason why one would want to narrow methods in subclasses] > If there really are systematic obstacles to narrowing OO types in > OCaml, not just beginner confusion on my part, is there some deep > reason? Perhaps because it causes problems with type inference? At > first I thought it might be because it tends to be strongly correlated > with typecase operations which miss the point of OO, but that doesn't > explain why I can't narrow the return type of a subclass method. You pointed it: type inference. Inferring class types is already pretty complicated, it would become nightmarish if method types can change with inheritance. Type inference is based on unification, which doesn't play well with subtyping. Since the problem is with inheritance, and not with subtyping, there are workarounds to define such classes. Basically the idea is to keep the type of self as a parameter to the class. class ['a] base_t ~pos ~friends = object method pos : int = pos method friends : 'a list = friends end class base = [base] base_t class ['a] extended_t ~pos ~friends ~name = object inherit ['a] base_t ~pos ~friends method name : string = name end class extended = [extended] extended_t Here are the types: class ['a] base_t : pos:int -> friends:'a list -> object method friends : 'a list method pos : int end class base : pos:int -> friends:base list -> [base] base_t class ['a] extended_t : pos:int -> friends:'a list -> name:string -> object method friends : 'a list method name : string method pos : int end class extended : pos:int -> friends:extended list -> name:string -> [extended] extended_t The point is that extended is actually a subtype of base: # let b = new base ~pos:1 ~friends:[(e : extended :> base)];; val b : base = Note that this only works as long as base has no contravariant method. If base_t contained an add_friend : 'a -> unit method, then subtyping would break. It might be possible to add method narrowing in the language with a special syntax, but again parametric classes are hard to handle. Cheers, Jacques Garrigue ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr