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 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 5080EBBC1 for ; Mon, 3 Mar 2008 20:29:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMLgy0fAXQImh2dsb2JhbACQdwEBAQgKKYENmyA X-IronPort-AV: E=Sophos;i="4.25,439,1199660400"; d="scan'208";a="7957763" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 03 Mar 2008 20:29:14 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m23JTB3r002095 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 3 Mar 2008 20:29:14 +0100 X-IronPort-AV: E=Sophos;i="4.25,439,1199660400"; d="scan'208";a="23315819" Received: from 109.215.100-84.rev.gaoland.net (HELO [192.168.0.3]) ([84.100.215.109]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2008 20:29:14 +0100 Message-ID: <47CC5092.1050100@irisa.fr> Date: Mon, 03 Mar 2008 20:25:06 +0100 From: Tiphaine Turpin User-Agent: Thunderbird 1.5.0.10 (X11/20070303) MIME-Version: 1.0 To: Keiko Nakata Cc: caml-list@inria.fr Subject: Re: [Caml-list] OO programming References: <47C81829.4010505@free.fr> <20080301.005807.125113032.keiko@kurims.kyoto-u.ac.jp> <47CBC7AB.9000601@free.fr> <20080304.001809.125117537.keiko@kurims.kyoto-u.ac.jp> In-Reply-To: <20080304.001809.125117537.keiko@kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 47CC5187.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; irisa:01 jacques's:01 verbose:01 parametric:01 camlp:01 parametric:01 'self:01 subset:01 recursive:01 verbose:01 functors:01 camlp:01 ocaml:01 beginner's:01 ocaml:01 Keiko Nakata a écrit : >>> 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? > Only experiments can tell us. But I suspect that using a systematic scheme for defining classes and relating them to each other should avoid users to make too many errors that come from a misunderstanding of the type system ('self escaping its scoope, or unified wit a closed type, etc.), thus allowing "advanced" use of caml objects by non type systems experts (including me). > 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.... > In this case where they are only made of (the same) types with a class type on one side and a private row type on the other side, this theoretical difference is far from obvious in practise, and this is one of the reasons why such code is so hard to read (as the same thing seem to be repeated twice). This would be nice if you could write your types once (possibly in a very small subset of the type language) and have the module and the module type be generated from the same code. > 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. > I plan to do some reasonable scale "OOcaml" coding (in my spare time) for some project. I will first see if I can use some systematic scheme successfully before I try anything with camlp4. That said, some of us tend to think of everything only from within ocaml, and I know that some day I should give a try to other systems, like Scala and its "traits". Tiphaine Turpin > Best, > Keiko > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > >