From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA16676 for caml-redistribution; Fri, 4 Sep 1998 09:12:01 +0200 (MET DST) 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 HAA03704 for ; Fri, 4 Sep 1998 07:53:15 +0200 (MET DST) Received: from csla.csl.sri.com (csla.csl.sri.com [192.12.33.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id HAA16485 for ; Fri, 4 Sep 1998 07:53:12 +0200 (MET DST) Received: from tulip.csl.sri.com.sri.com (tulip.csl.sri.com [130.107.4.31]) by csla.csl.sri.com (8.8.7/8.8.7) with SMTP id WAA25004 for ; Thu, 3 Sep 1998 22:53:05 -0700 (PDT) Date: Thu, 3 Sep 1998 22:53:05 -0700 (PDT) Message-Id: <199809040553.WAA25004@csla.csl.sri.com> Received: by tulip.csl.sri.com.sri.com (4.1/SMI-4.1) id AA10396; Thu, 3 Sep 98 22:52:54 PDT From: David Monniaux Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: caml-list@inria.fr Subject: inheritance for functor ? In-Reply-To: <35E3C6E9.BAFFE611@univ-savoie.fr> References: <35E3C6E9.BAFFE611@univ-savoie.fr> X-Mailer: VM 6.33 under Emacs 19.34.1 Sender: weis Christophe Raffalli writes: > module type Euclidian_Ring = > sig > import Ring > type nt > val norm : t -> nt > val leq : nt -> nt -> bool > val (//) : t -> t -> t > val (mod) : t -> t -> t > val div_mod : t -> t -> t * t > end inherit would not add another keyword. Such a feature looks highly desirable (especially for examples such as yours, with mathematical structures). Also, it looks easy to implement. High fives to the implementors for let module = ... in ... Remark: it's not possible to hide a 'new classtype' function in a signature. That looks useful in certain circumstances, like mlgtk with its classes taking a pointer into a C structure as a parameter. However, this is not a must at all; after all, the library user is supposed to be big enough to understand that some functions shouldn't be used, period. Now about mlgtk. I've recently had demands for it. I plan to add all the gtk library functions and the data structure accessors as soon as possible. Partial versions will be posted on my WWW page (http://www.eleves.ens.fr:8080/home/monniaux). Talking of which, what are the perspectives on variances? In ML-gtk, I have classes such as button, label, all descending from widget. Certain functions take a widget list as an argument. The problem is that the user has to do the casts manually: [((foobar constructing a button) :> widget); ((foobar constructing a label) :> widget)] which is quite heavy. Is there any way to make it look better? -- David Monniaux, PhD student at ENS, Paris, France Now at: Computer science laboratory SRI International Formal methods group Menlo Park, CA, US http://www.csl.sri.com/~monniaux