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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 25E50BBCA for ; Thu, 28 Feb 2008 16:18:42 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFRfxkfAXQInh2dsb2JhbACQcQEBAQgKKYENm2Y X-IronPort-AV: E=Sophos;i="4.25,419,1199660400"; d="scan'208";a="9710581" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Feb 2008 16:18:42 +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 m1SFIfHb032207 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 28 Feb 2008 16:18:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFRfxkeCNhAB/2dsb2JhbACSPJtm X-IronPort-AV: E=Sophos;i="4.25,419,1199660400"; d="scan'208";a="9710580" Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Feb 2008 16:18:40 +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 m1SFIcdQ028347 for ; Fri, 29 Feb 2008 00:18:38 +0900 (JST) Date: Fri, 29 Feb 2008 00:18:38 +0900 (JST) Message-Id: <20080229.001838.74181273.keiko@kurims.kyoto-u.ac.jp> To: caml-list@inria.fr Subject: Re: [Caml-list] OO programming From: Keiko Nakata In-Reply-To: <47C6B774.8070308@fmf.uni-lj.si> References: <20080227.103733.43387508.garrigue@math.nagoya-u.ac.jp> <20080228.173429.68546494.keiko@kurims.kyoto-u.ac.jp> <47C6B774.8070308@fmf.uni-lj.si> 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 47C6D0D1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; functor:01 struct:01 sig:01 struct:01 val:01 sig:01 val:01 functor:01 trivialities:01 functors:01 signatures:01 precedence:01 caml-list:01 parameter:02 parameter:02 > I have three wishes related to the case when a functor accepts a > structure that contains a single type or a single value: > > 1) To be able to write > > module F(type t) = struct ...t... end > > instead of > > module F(T : sig type t end) = struct ... T.t ... end > > and to write > > F(s) > > instead of > > F(struct type t = s end) > > 2) Similarly for values, to be able to write > > module F(val x : t) = struct ... x ... end > > instead of > > module F(T : sig val x : t end) = struct ... T.x ... end > > 3) Similarly for signatures: > > module type F = functor type t -> sig ... end > > module type F = functor val x : t -> sig ... end > > I believe these are campl4 trivialities. There may be some hoxus-pocus > related to generating suitable names for T's above. This is merely my personal preference, but I usually do not prefer implicit construction of names; for instance I may well get confused by type error messages. Besides in this scenario: > module F(type t) = struct ...t... end we need to decide which take precedence if the structure declares a type component named t. On the other hand, since the functor parameter has the role of the super class in the functor&fix-point approach to OO-style programming, it may well be useful to have an implicit way to refer to components of the parameter, as you proposed. Yet this may be confusing again if we consider multi-parameter functors a la multiple inheritance. What do you think? With best regards, Keiko