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 SAA18742; Wed, 14 Nov 2001 18:42:38 +0100 (MET) 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 SAA18086 for ; Wed, 14 Nov 2001 18:42:37 +0100 (MET) Received: from mx5.airmail.net (mx5.airmail.net [209.196.77.102]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAEHgaX03782 for ; Wed, 14 Nov 2001 18:42:36 +0100 (MET) Received: from covert.black-ring.iadfw.net ([209.196.123.142]) by mx5.airmail.net with smtp (Exim 3.16 #10) id 16443Y-000KOa-00 for caml-list@inria.fr; Wed, 14 Nov 2001 11:42:36 -0600 Received: from rootless.localdomain from [207.136.49.111] by covert.black-ring.iadfw.net (/\##/\ Smail3.1.30.16 #30.55) with esmtp for sender: id ; Wed, 14 Nov 2001 11:43:55 -0600 (CST) Received: (from newman@localhost) by rootless.localdomain (8.10.1/8.10.1) id fAEHH8K14256; Wed, 14 Nov 2001 11:17:08 -0600 (CST) Date: Wed, 14 Nov 2001 11:17:08 -0600 From: William Harold Newman To: caml-list@inria.fr Subject: [Caml-list] difficulties narrowing OO types Message-ID: <20011114111708.A14071@rootless> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk OCaml seems generally reluctant to narrow OO types. 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). 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. I'm still trying to understand the language, so it was only as I was trying to express what I thought was an analogous limitation for variant types I realized that there seems to be no such limitation after all. I can define types like type tagged_reg = { tagged_n : int } ;; type untagged_reg = { untagged_n : int } ;; type reg = Tagged_Reg of tagged_reg | Untagged_Reg of untagged_reg ;; and then define things like let rec tagged_regs regs = match regs with | [] -> [] | Tagged_Reg(tr) :: rest -> tr :: tagged_regs rest | Untagged_Reg(_) :: rest -> tagged_regs rest ;; But I still don't see how to do things like this with classes. My immediate motivation for thinking about narrowing types is that I have a class "sq" which lives on a grid where I know from global constraints that all the other "sq" objects on the grid are of the same class, and furthermore that this will be true of any subclasses. I.e. if it's a pure "sq", all elements of its grid will be pure "sq" also, and it it's a subclassed objects "subsq" all elements will be "subsq", and so on for "subsubsq" and "subsubsubsq" and so forth. I'd like to be able to define a "neighbors" method which returns a list of "sq" when the object is exactly of class "sq", and returns a list of "subsq" when the object is exactly of class "subsq", and so on. Or, I'd be satisfied with a "map_on_neighbors" function which mapped onto neighboring "sq" objects in the "sq" case, and neighboring "subsq" objects in the "subsq" case, and so forth. An approximate analogy in the register example above might be functions like "colliding_regs" or "alternative_regs" which are meaningful both for tagged and untagged registers, and return only values of the same type as their register argument. 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. -- William Harold Newman PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C ------------------- 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