From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 0624CBC48 for ; Wed, 6 Apr 2005 21:34:00 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j36JXxK1025406 for ; Wed, 6 Apr 2005 21:33:59 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA15811 for ; Wed, 6 Apr 2005 21:33:59 +0200 (MET DST) Received: from saul.cis.upenn.edu (SAUL.CIS.upenn.edu [158.130.12.4]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j36JXvIv007271 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 6 Apr 2005 21:33:58 +0200 Received: from localhost (SAUL.CIS.upenn.edu [158.130.12.4]) by saul.cis.upenn.edu (8.12.10/8.12.9) with ESMTP id j36JXuCP008999; Wed, 6 Apr 2005 15:33:56 -0400 (EDT) Date: Wed, 06 Apr 2005 15:33:56 -0400 (EDT) Message-Id: <20050406.153356.35007840.eijiro_sumii@anet.ne.jp> To: caml-list@inria.fr Cc: sumii@saul.cis.upenn.edu Subject: Re: [Caml-list] ambitious proposal: polymorphic arithmetics From: Eijiro Sumii In-Reply-To: <20050406163915.GC15547@force.stwing.upenn.edu> References: <20050406.111505.68543084.eijiro_sumii@anet.ne.jp> <20050406163915.GC15547@force.stwing.upenn.edu> X-Mailer: Mew version 3.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 425439A7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 425439A5.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 eijiro:01 sumii:01 eijiro:01 sumii:01 lovas:01 wlovas:01 stwing:01 upenn:01 inputs:01 abstraction:01 exception:01 exception:01 polymorphic:01 polymorphic:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: From: "William Lovas" > More seriously, one might argue -- only slightly hand-wavily -- that with > =, <, etc., types whose values *cannot* be used as inputs are the exception > rather than the rule, whereas the reverse is the case for +, -, etc. For > example, it may be perfectly clear (or at least possible to specify) how to > implement comparisons on data types, records, and tuples. What should the > arithmetic operators mean on such things? I don't quite think comparisons are clearer (or "more possible" to specify) than additions for tuples and records - they can be defined just element-wise. Data types indeed seem more problematic as pointed out in other replies. > (This argument breaks down in > the face of code which relies on abstract types to enforce modularity -- in > such cases, incomparability can become "the rule" rather than the > exception, putting =, <, etc. on the same footing as +, -, etc.) Yes, polymorphic comparison already breaks type abstraction. Eijiro