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 CC766BB94 for ; Mon, 27 Dec 2004 03:46:56 +0100 (CET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBR2ksSN025016 for ; Mon, 27 Dec 2004 03:46:56 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id iBR2OPQc016174; Mon, 27 Dec 2004 11:24:25 +0900 (JST) Date: Mon, 27 Dec 2004 11:24:08 +0900 (JST) Message-Id: <20041227.112408.18229510.garrigue@math.nagoya-u.ac.jp> To: nystrom@cs.cornell.edu Cc: caml-list@yquem.inria.fr, andru@cs.cornell.edu Subject: Re: [Caml-list] Possibility of Nested Classes and Nested Inheritance? From: Jacques Garrigue In-Reply-To: References: <20041217184433.GA1036@balm.cs.cornell.edu> X-Mailer: Mew version 4.0.64 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41CF779E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 cornell:01 recursion:01 compiler:01 recursive:01 recursion:01 wwwfun:01 mixin:01 fixpoint:01 modular:01 avoiding:01 ad-hoc:01 defaults:01 checker:01 invoke: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: A small complement to my previous post. From: Nate Nystrom > 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 > 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. This kind of practical problems could be easily solved by syntactic sugar. Yet, you can see a direct approach (without sugar) in this code sample http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/mixin2.ml.txt The idea is to use classes like modules with inheritance and recursion (using lazyness to get a fixpoint). So we get closer to your approach. (I've cleaned-up a little, but this code has been at this URL for years.) Another more general remark, which might seem somehow contradictory, is that functional programs do not have the same notion of modularity. In particular, as the typing helps a lot, this is not seen as a problem to directly modify existing code (which modular extension prohibits). So one writes code with the possibility of future modifications in mind, making it more robust by avoiding ad-hoc defaults. When you have no default, the type checker can track changes to types, and force you to modify relevant code. Jacques Garrigue