From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 8CEDFBB81 for ; Fri, 24 Dec 2004 20:48:49 +0100 (CET) Received: from exchfe2.cs.cornell.edu (exchfenlb-2.cs.cornell.edu [128.84.97.34]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBOJmm7Q025092 for ; Fri, 24 Dec 2004 20:48:49 +0100 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Dec 2004 14:48:40 -0500 Received: from [192.168.0.101] ([69.241.164.242]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Dec 2004 14:48:39 -0500 In-Reply-To: <20041217184433.GA1036@balm.cs.cornell.edu> References: <20041217184433.GA1036@balm.cs.cornell.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Andrew Myers From: Nate Nystrom Subject: Re: [Caml-list] Possibility of Nested Classes and Nested Inheritance? Date: Fri, 24 Dec 2004 14:48:41 -0500 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 24 Dec 2004 19:48:39.0879 (UTC) FILETIME=[90CA6570:01C4E9F1] X-Miltered: at concorde with ID 41CC72A0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; cornell:01 caml-list:01 scalable:01 ocaml:01 polymorphism:01 implicitly:01 enclosing:01 polymorphism:01 ocaml:01 variants:01 cited:01 compiler:01 scalable:01 variants:01 wwwfun:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: From: Jacques Garrigue > From: "J=F8rgen Hermanrud Fjeld" > >> I just read about the work by Nystrom, Chong and Myers on nested >> inheritance, specifically the article "Scalable Extensibility via=20 >> Nested Inheritance". >> >> The article does demonstrate fascinating, to me, use of inheritance,=20= >> and I wonder if it is possible to do something similar and >> object-oriented in OCaml. >> >> To do something similar would, according to my understanding, require >> both inner classes and super-class polymorphism. >> In understand inner classes as implicitly polymorphic with respect >> to the enclosing class, >> and polymorphism on the super class as the practical ability to = extend >> the type hierarchy upwards. >> >> Do you know of any work that relate nested inheritance to OCaml, or=20= >> that >> address the similar issuesof inner classes and super-class=20 >> polymorphism? > > Answer 1: there are no inner classes in ocaml. Another alternative is to use nested inheritance with modules. This likely requires that module inheritance be added to the language, although there may be other approaches that fit in better with the ocaml module system. In fact, we expect that in Jx (our extension of Java=20 with nested inheritance) package inheritance will be the main use of nested inheritance. > Answer 2: there are plenty of other ways to obtain similar effects. > > I don't know exactly what fascinated you in the paper, so it is hard > to answer precisely, but there are already a few techniques in ocaml = to > solve the problems they describe. > (Of course they wouldn't cite them, as ocaml doesn't look like a > relevant language to them.) I admit I was unaware of polymorphic variants. I certainly would have cited ocaml had I been aware of them. > > Their compiler example seems to be a variant of the expression > problem. The expression problem is an instance of what we call scalable extensibility. > There are several solutions to the expression problem in ocaml, using > either polymorphic variants > http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/fose2000.html I don't see how polymorphic variants solve the expression problem. As I understand them, if I were to implement a compiler using=20 polymorphic variants, I would create a variant for each term in the language, then write functions that match against those variants to implement the compiler passes. However, if I want to add a new term to the language, I would have to add a new variant, then write new functions for each of the compiler passes to handle the new variant, delegating to the old functions for the old variants. Thus if I have n passes implemented as functions, I have to write O(n) code to add a new term. Please correct me if I'm wrong on this. Zenger and Odersky's ICFP'00 paper on extensible algebraic datatypes with defaults addresses this particular problem. Furthermore, to allow extension, recursion is left open for the functions implementing the compiler passes and then closed in order to invoke the function on a particular type. Thus, when a new=20= variant is added, a small amount of code for each open recursive function needs to be written to close the recursion with the new type. > or objects > http://pauillac.inria.fr/~remy/work/expr/ > > On the more general question of virtual types, Didier R=E9my and = J=E9r=F4me > Vouillon gave a detailed "refutation". > http://pauillac.inria.fr/~remy/work/virtual/ This paper shows that you can use parametric polymorphism to solve the same problems virtual types were designed to address. The problem to look out for with this approach is that you may end up parameterizing a class on a large number of related classes, e.g., parameterizing a compiler pass class on every AST node class (in our Java compiler, there are 40-50 such classes). This paper argues that, in practice, you won't have too many parameters because you only need to parameterize on types on which there is actually a constraint. I think this does not work with our compiler problem. Using the traditional visitor pattern, you will have to parameterize the visitor class on every AST node class. > So you can see if you can do all what you need with the above methods. > If you find some unexpected limitation, please let us now. > > Jacques Garrigue Nate