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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id F0BDABC0A for ; Wed, 28 Feb 2007 04:21:41 +0100 (CET) Received: from mail16.bluewin.ch (mail16.bluewin.ch [195.186.19.63]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1S3Lfei030916 for ; Wed, 28 Feb 2007 04:21:41 +0100 Received: from [10.0.1.2] (85.2.126.110) by mail16.bluewin.ch (Bluewin 7.3.121) id 45C31D3F0060BAEE for caml-list@inria.fr; Wed, 28 Feb 2007 03:21:41 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <1172627876.19033.85.camel@rosella.wigram> References: <301730110702271322m72d20cffh37bddb14dc91b6f9@mail.gmail.com> <20070228.092306.92341518.garrigue@math.nagoya-u.ac.jp> <4a708d20702271718r3fa74211jbf81372bc9fb8b79@mail.gmail.com> <20070228.103403.105433774.garrigue@math.nagoya-u.ac.jp> <1172627876.19033.85.camel@rosella.wigram> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8DF1B76F-AE3B-43F2-9034-7CF47277EE7B@epfl.ch> 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 04:23:27 +0100 To: OCaml Mailing List X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 45E4F545.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 explicitely:01 invariants:01 semantics:01 undecidable:01 fulfilled:98 polymorphic:01 polymorphic:01 beginners:01 typing:01 typing:01 caml-list:01 define:01 Le 28 f=E9vr. 07 =E0 02:57, skaller a =E9crit : > After all a nominal type is just a structural type with > a unique tag representing its unique name. What you miss here is the _process_ behind nominal types. (paraphrasing Jacques) Types are not precise enough to define the =20 semantic of a function, multiplication and addition have the same =20 type but in many cases you cannot exchange one for the other. With =20 that respect structural typing is a fallacy, it is not because types =20 match that you can replace a function by another. With a nominal type the programmer signals explicitely its intent to =20 support a semantic. Notably you cannot use a function in a given =20 context if it was not designed for that purpose which sounds =20 fascistic but makes sense from a software development point of view. Structural typing would make sense if it involved the weakest =20 invariants a function. But for now, because of the poor information =20 types give about semantics, structural typing is just bureaucratic =20 compliance whereas nominal typing is a semantic contract --- whether =20 actually fulfilled or not is another (undecidable) question. Daniel