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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id B733EBC0A for ; Wed, 28 Feb 2007 14:46:18 +0100 (CET) Received: from mail21.bluewin.ch (mail21.bluewin.ch [195.186.18.66]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1SDkIcW032725 for ; Wed, 28 Feb 2007 14:46:18 +0100 Received: from [10.0.1.2] (85.2.64.245) by mail21.bluewin.ch (Bluewin 7.3.121) id 45C321870078AE4C; Wed, 28 Feb 2007 13:46:12 +0000 In-Reply-To: <20070228.130115.35466734.garrigue@math.nagoya-u.ac.jp> References: <20070228.103403.105433774.garrigue@math.nagoya-u.ac.jp> <1172627876.19033.85.camel@rosella.wigram> <8DF1B76F-AE3B-43F2-9034-7CF47277EE7B@epfl.ch> <20070228.130115.35466734.garrigue@math.nagoya-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2BFFE1D1-1C1B-4E33-B3AD-C75A30B5E58D@epfl.ch> Cc: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Fwd: "ocaml_beginners"::[] Trouble combining polymorphic classes and polymorphic methods Date: Wed, 28 Feb 2007 14:47:59 +0100 To: Jacques Garrigue X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 45E587AA.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 usefull:01 compiler:01 functor:01 functor:01 explictely:01 reuse:01 foresee:98 polymorphic:01 polymorphic:01 beginners:01 dynamically:01 caml-list:01 Le 28 f=E9vr. 07 =E0 05:01, Jacques Garrigue a =E9crit : > Wow, here is a strong statement. Basically, you seem to be saying that > types are useless for safety if they don't ensure full correctness, > and that in the absence of safety they need to be nominal in order to > declare any intent? I think you took the statement stronger that I intended (my fault). =20 I'm certainly not saying types are useless for safety without =20 correctness. I find it _immensely_ usefull that a machine takes care =20 of the bureaucracy of types and I often wonder, when the compiler =20 reminds me, how bad my software development would be in a dynamically =20= typed language -- not even talking about those in which you don't =20 declare your identifiers. My statement was really about the module system part of the type =20 system. I sometimes find it a little bit artificial that if your =20 module structuraly matches a signature you can pass it to a functor. =20 If you take the point of view of a programmer who is provided with =20 modules he didn't write, I think it makes it easier for him to make =20 correct functor applications in a nominal setting because modules =20 explictely indicate that they were designed to support a given =20 interface. On the other hand, nominality hinders code reuse since you =20= may found a use that the initial programmer couldn't ever foresee. =20 But this problem can be alleviated by a simple construct that allows =20 to extend a module to support a new interface (even if no new code =20 needs to be written). Besides that, I agree with most of your points, even though your =20 `Apples may be oranges to me but I quite buy your probabilistic =20 argument. Best, Daniel