From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id BF74CBC48 for ; Wed, 6 Apr 2005 18:39:20 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j36GdKQG020749 for ; Wed, 6 Apr 2005 18:39:20 +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 SAA11058 for ; Wed, 6 Apr 2005 18:39:19 +0200 (MET DST) Received: from nexus.stwing.upenn.edu (NEXUS.STWING.UPENN.EDU [165.123.132.61]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j36GdIrW020746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Apr 2005 18:39:19 +0200 Received: from localhost (localhost [127.0.0.1]) by nexus.stwing.upenn.edu (Postfix) with ESMTP id D23CC64987 for ; Wed, 6 Apr 2005 12:39:17 -0400 (EDT) Received: from nexus.stwing.upenn.edu ([127.0.0.1]) by localhost (nexus.stwing.upenn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19967-06 for ; Wed, 6 Apr 2005 12:39:17 -0400 (EDT) Received: from force.stwing.upenn.edu (force.stwing.upenn.edu [165.123.132.65]) by nexus.stwing.upenn.edu (Postfix) with ESMTP id 5203F64944 for ; Wed, 6 Apr 2005 12:39:17 -0400 (EDT) Received: by force.stwing.upenn.edu (Postfix, from userid 5302) id E87FD31F10; Wed, 6 Apr 2005 12:39:16 -0400 (EDT) Date: Wed, 6 Apr 2005 12:39:16 -0400 From: William Lovas To: caml-list@inria.fr Subject: Re: [Caml-list] ambitious proposal: polymorphic arithmetics Message-ID: <20050406163915.GC15547@force.stwing.upenn.edu> Mail-Followup-To: caml-list@inria.fr References: <20050406.111505.68543084.eijiro_sumii@anet.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050406.111505.68543084.eijiro_sumii@anet.ne.jp> User-Agent: Mutt/1.5.6i X-Virus-Scanned: amavisd-new at stwing.upenn.edu X-Miltered: at nez-perce with ID 425410B8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 425410B6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; lovas:01 wlovas:01 stwing:01 upenn:01 caml-list:01 eijiro:01 eijiro:01 sumii:01 integers:01 inputs:01 cheers:01 ...:98 wrote:01 exception:01 exception: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: Hi Eijiro, On Wed, Apr 06, 2005 at 11:15:05AM -0400, Eijiro Sumii wrote: > So here it goes: why don't we have polymorphic +, -, etc. while we > have polymorphic =, <, etc.? Many novices and (at least) some experts > feel that +., -., etc. are not quite nice. Why not define +, -, > etc. for as many types as possible such as integers, floating-point > numbers, and tuples? I think they can be implemented almost in the > same efficient way as =. They can also raise an exception if applied > to unsupported values such as functions, just as = does. Many experts (and perhaps some novices *shrug*) think that polymorphic equality is a bad idea... so maybe it's best to just leave "well enough" alone :) 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? (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.) These are just my thoughts, though, and i'm still something of a nameless student :) cheers, William