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 BAA25382; Wed, 26 Mar 2003 01:58:46 +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 BAA25690 for ; Wed, 26 Mar 2003 01:58:44 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h2Q0waf11327 for ; Wed, 26 Mar 2003 01:58:39 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id JAA00785; Wed, 26 Mar 2003 09:58:29 +0900 (JST) To: sebastien.briais@epfl.ch Cc: caml-list@inria.fr Subject: Re: [Caml-list] About polymorphic methods and recursive classes In-Reply-To: <3E80547E.2010201@epfl.ch> References: <3E7F457A.80006@epfl.ch> <20030325101545S.garrigue@kurims.kyoto-u.ac.jp> <3E80547E.2010201@epfl.ch> 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: <20030326095842K.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 26 Mar 2003 09:58:42 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Spam: no; 0.00; jacques:01 caml-list:01 inferred:01 unroll:01 recursion:01 alist:01 generic:01 ml-style:01 inference:01 bug:01 reasonnable:01 avoiding:01 ocaml:01 caml:01 workaround:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Sebastien Briais > >Actually no. Polymorphic methods are not inferred, but declared. > >And polymorphic type variables should not be used as parameters to > >simultaneously defined types. > >Actually, your mutually recursive definition should not be accepted to > >begin with. It clearly results in a wrong internal type. > > > So, if I understand you well, it is not possible to write something like > that in ocaml: > > class virtual ['a,'b] list_visitor = > object > method virtual caseNil : 'a > method virtual caseCons : 'b -> 'b list -> 'a > end > and virtual ['b] list = > object > method virtual visit : 'a.(('a,'b) list_visitor -> 'a) > end Right. The only workaround I see is to unroll the recursion: class type ['a,'b,'c] list_visitor_t = object method caseNil : 'a method caseCons : 'b -> 'c -> 'a end class type ['b] alist = object method visit : 'a. ('a,'b,'b alist) list_visitor_t -> 'a end class type ['a,'b] list_lisitor = ['a,'b,'b alist] list_visitor_t class ['b] nil = object (_ : 'b #alist) method visit x = x#caseNil end class ['b] cons h t = object (_ : 'b #alist) method visit x = x#caseCons h t end I agree this is not a very intuitive solution. > But what is the reason of this limitation ? > I do not see the reasons since for example, in Generic Java, such a > definition is correct. Generic Java is another language, and it does not have ML-style type inference. It is very hard to compare. There are lots of tricks you can do with type inference that you cannot do with a fully declared language. For those who remember old discussions about loss of polymorphism in mutually recursive type definitions in earlier versions of caml, this is related: in order to propagate type constraints, type variables in class definitions are only generalized after then end of the whole definition, which in this case is too late. You can also see this as bug, and not so easy to fix. > Can you explain in more details your answer ? > Does it lead to type insafety or indecidability of typing to authorize > polymorphic type variables to be used as parameters to > simulteanously defined types ? According to the target you choose, this can probably lead to indecidabilty. There should be some reasonnable solution, avoiding going too far, but the interaction with constraints is going to be really hard to avoid. I was unaware of this problem until it was posted on this list. 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