From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 42D6EBBC1 for ; Mon, 3 Mar 2008 16:18:25 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABaly0fAXQInh2dsb2JhbACQcgEBAQgKKZtL X-IronPort-AV: E=Sophos;i="4.25,438,1199660400"; d="scan'208";a="23301385" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Mar 2008 16:18:25 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m23FIOaJ027128 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 3 Mar 2008 16:18:24 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADqly0eCNhAB/2dsb2JhbACsfA X-IronPort-AV: E=Sophos;i="4.25,438,1199660400"; d="scan'208";a="9836281" Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Mar 2008 16:18:22 +0100 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id m23FI9mX012248 for ; Tue, 4 Mar 2008 00:18:20 +0900 (JST) Date: Tue, 04 Mar 2008 00:18:09 +0900 (JST) Message-Id: <20080304.001809.125117537.keiko@kurims.kyoto-u.ac.jp> To: caml-list@inria.fr Subject: Re: [Caml-list] OO programming From: Keiko Nakata In-Reply-To: <47CBC7AB.9000601@free.fr> References: <47C81829.4010505@free.fr> <20080301.005807.125113032.keiko@kurims.kyoto-u.ac.jp> <47CBC7AB.9000601@free.fr> X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47CC16C0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; jacques's:01 verbose:01 parametric:01 camlp:01 parametric:01 recursive:01 verbose:01 functors:01 abstract:01 syntactic:01 caml-list:01 inherit:01 oop:01 modularity:02 structures:02 > > As I see Jacques's code, he gradually extends the module type S > > to S' and S''. Type declarations in module types and type definitions > > in structures involving types event, observer and subject are duplicated > > everywhere with slight modifications. > > Why can we not extend the previously defined module type > > in a less verbose way? > > > I agree. Maybe the idea of using parametric class type definitions (in > WRichT) and defining unparameterized types afterwards (in S'') could be > helpfull, as such definitions can be extended with the "inherit > " construct. Otherwise you would need to keep syntaxically > the successive declarations with camlp4 for future use, which is not > very handy. Parametric class type definitions should be helpful. We might need as many type parameters as (class) type definitions involved; do you think this can be problematic, particularly in respect of type error messages? Hopefully we want to start with S and derive its refinements by extending S bit by bit. But here is one problem: module type declarations (e.g. S) and structures (e.g. WindowA) are completely different entities; it can be handy in practice if we can include S in WihdowA and refine the included types by giving concrete representations to abstract types (e.g. event). Well, I know that module types and structures are indeed completely different from the theoretical point of view.... Here is another thing that may be worth attention. The types observer and subject in WRichT are not recursive, but we take their fix-point in S''. Unfortunately we cannot do this kind of refinement via the "with" construct. Anyway, I think we are almost exactly following OO-programming style in a more explicit thus more verbose way. So I conjecture that if we come up with good syntactic sugar, we can be as concise as OOP; as you suggest it may well be a good idea to expand the sugar into parametric class definitions, possibly combined with functors and private row types to increase modularity. Best, Keiko